Re: LSP is Microsoft's patented protocol - Re: Emacs as an Org LSP server

[Christopher Dimech]

> Sent: Tuesday, December 15, 2020 at 7:25 AM
> From: "Jean Louis" 
> To: "Christopher Dimech" 
> Cc: neiljer...@gmail.com, emacs-orgmode@gnu.org, "Richard Stallman" 
> , tecos...@gmail.com
> Subject: Re: LSP is Microsoft's patented protocol - Re: Emacs as an Org LSP 
> server
>
> I can understand that GNU and Org shall ignore patents and continue without 
> putting attention.

Lawyers worth their salt will also tell you to ignore them.

> Jean
>
>

Re: LSP is Microsoft's patented protocol - Re: Emacs as an Org LSP server

[Jean Louis]

I can understand that GNU and Org shall ignore patents and continue without 
putting attention.


Jean

Re: LSP is Microsoft's patented protocol - Re: Emacs as an Org LSP server

[Christopher Dimech]

Daniel Ravicher found 283 software patents that, if upheld as valid by the 
courts, could potentially be used to support patent claims upon the Linux 
Kernel.  I wonder how many more for Free Software in general!

-
Christopher Dimech
General Administrator - Naiad Informatics - GNU Project (Geocomputation)
- Geophysical Simulation
- Geological Subsurface Mapping
- Disaster Preparedness and Mitigation
- Natural Resource Exploration and Production
- Free Software Advocacy


> Sent: Tuesday, December 15, 2020 at 6:50 AM
> From: "Jean Louis" 
> To: "Richard Stallman" 
> Cc: neiljer...@gmail.com, emacs-orgmode@gnu.org, tecos...@gmail.com
> Subject: Re: LSP is Microsoft's patented protocol - Re: Emacs as an Org LSP 
> server
>
> * Richard Stallman  [2020-12-15 08:48]:
> > [[[ To any NSA and FBI agents reading my email: please consider]]]
> > [[[ whether defending the US Constitution against all enemies, ]]]
> > [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> >
> >   > Do you have evidence it is not patented?
> >
> > That sort of question is not useful to ask.
> > No one _ever_ has evidence that any given thing
> > is not patented.
>
> I was expecting a reference where Microsoft explains it is free in one
> way or the other, whereby I could not find it myself.
>
> Jean
>
>

Re: LSP is Microsoft's patented protocol - Re: Emacs as an Org LSP server

[Jean Louis]

* Richard Stallman  [2020-12-15 08:48]:
> [[[ To any NSA and FBI agents reading my email: please consider]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > Do you have evidence it is not patented?
> 
> That sort of question is not useful to ask.
> No one _ever_ has evidence that any given thing
> is not patented.

I was expecting a reference where Microsoft explains it is free in one
way or the other, whereby I could not find it myself.

Jean

Re: LSP is Microsoft's patented protocol - Re: Emacs as an Org LSP server

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Do you have evidence it is not patented?

That sort of question is not useful to ask.
No one _ever_ has evidence that any given thing
is not patented.

Unless we see a specific practical problem,
the thing to do is just ignore the danger of patents.
The danger does exist, but worrying about it in advance
is futile and damaging.  It is like worrying that
a meteorite might fall and hit you.  There is a small
chance of that, but worrying about it is useless.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Bring up a screen giving option to open a series of orgmode files

[Jean Louis]

* Ihor Radchenko  [2020-12-15 07:39]:
> TRS-80  writes:
> 
> > We are getting further and further afield from Orgmode discussion,
> > however I wanted to share the following article with anyone else who
> > followed this part of the thread all the way to this point:
> 
> Oops. Actually, hypothes.is is related to org-mode in my mind. Mostly as
> a reference of implementation of fine-grained links to
> web-pages/documents. I wish org-mode links had universal support to
> position inside the document the link is pointing to (similar what is
> already present in file link to org files, where we can refer to
> specific heading inside the referenced file). It would be great if
> org-mode extended the link syntax to define position inside the text
> file/web-page/video/pdf/etc. Then, packages like org-pdftools would not
> need to invent new link types just to be able to refer to specific page
> or annotation inside a pdf file.

For PDF and video with specific start time I am using different type
of hyperlinks and not Org hyperlinks. So I was under impression that
Org hyperlinks to PDF support specific page. I have even prepared
myself to start including such in instructional manual. But do they?
It implies that PDF viewer setting should be per user configurable to
accept the page argument.

One possible solution could be this. For annotations, hypothes.is uses
Javascript library http://annotatorjs.org/ and I have not finished
research of it. I just have some slight idea that the whole annotation
and position of annotation could be captured in a hyperlink to it by
using that library.

That, if only possible, would enable Org without further modifications
to use hyperlinks to annotated online WWW pages and online PDFs.

Maybe you know Javascript and you can try?

Re: Bug: org-capture does not work if called from minibuffer [9.4 (9.4-55-g706ba9-elpaplus @ /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20201207/)]

[Jean Louis]

* Omar Antolín Camarena  [2020-12-15 03:40]:
> > On my side that works. When it is enabled I get screen for Org capture
> > and I can do it.
> 
> Odd, it definitely does not work here. If I call org-capture from the
> minibuffer, the *Org Select* buffer does appear, but choosing any
> template produces an error message of the form:
> 
> org-capture: Capture template ‘j’: Can’t expand minibuffer to full
> frame

You are right, I did not complete the task, and that error is
there. I don't think it is hard to make it work. I have tried my
personal recursive buffer editing and other function and such work in
recursive minibuffer, so it indicates that function org-capture could
be made better that it works in every condition.

Re: Bring up a screen giving option to open a series of orgmode files

[Ihor Radchenko]

TRS-80  writes:

> We are getting further and further afield from Orgmode discussion,
> however I wanted to share the following article with anyone else who
> followed this part of the thread all the way to this point:

Oops. Actually, hypothes.is is related to org-mode in my mind. Mostly as
a reference of implementation of fine-grained links to
web-pages/documents. I wish org-mode links had universal support to
position inside the document the link is pointing to (similar what is
already present in file link to org files, where we can refer to
specific heading inside the referenced file). It would be great if
org-mode extended the link syntax to define position inside the text
file/web-page/video/pdf/etc. Then, packages like org-pdftools would not
need to invent new link types just to be able to refer to specific page
or annotation inside a pdf file.

The relevant feature request is in my todo list.

Best,
Ihor

Re: org-todo-yesterday with 1-day repeater tasks: repeats tomorrow

[Ihor Radchenko]

Ken Mankoff  writes:
> Hello list,
> Are other experiencing this behavior? Is there some prefix arg I am missing 
> that I should be using? I have not found other complaining about this 
> behavior or reporting this issue, so I wonder if I'm missing something. If 
> not, I'll work on submitting a patch.

I do not need this setting most of time, but I do not remember issues
with repeaters (maybe I just never noticed them though). However, there
is one more relevant variable you might want to look into:
org-use-effective-time 

Best,
Ihor

Re: Bug: org-capture does not work if called from minibuffer [9.4 (9.4-55-g706ba9-elpaplus @ /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20201207/)]

[Omar Antolín Camarena]

> On my side that works. When it is enabled I get screen for Org capture
> and I can do it.

Odd, it definitely does not work here. If I call org-capture from the
minibuffer, the *Org Select* buffer does appear, but choosing any
template produces an error message of the form:

org-capture: Capture template ‘j’: Can’t expand minibuffer to full frame

> One solution you can use is that you open separate Emacs instance or
> Emacs as server that loads org-capture and serves for capturing
> things. It may run in background without interrupting your work. It
> can then spawn emacsclient to annotate or write the captured note.

Sure, but a much simpler solution is to exit the minibuffer before
calling org-capture. *shrug*

-- 
Omar

Re: Emacs as an Org LSP server

[Jean Louis]

* Dominik Schrempf  [2020-12-15 01:36]:
> I think this is an excellent idea. However, I am not familiar with the legal
> aspects mentioned by Jean.

I hope there will be no legal problems and that my statements will be
proven as wrong.

> So far I had good experiences with language servers.  On the other
> side, Org mode is Emacs specific, so this argument does not really
> apply. Do we want Org mode to stay Emacs specific? I don't know.

Org mode has many connections to Open Hyperdocument Template by Doug
Engelbart. The Augment system that has been demonstrated back in maybe
1968 fantastic features that Org mode does not support today in
2020. One of those features is collaboration.

To make Org mode non-software centric is good motion. As if we claim
it is plain text, then plain text may be implemented by other
editors. That boosts or opens first steps to more collaboration. I do
not see LSP server that as good collaboration method, but it can open
various editors to that.

What would be more collaborative is to extend the Org-LSP to read
information from Emacs instance and provide Org structure to its
clients. As Org is not just a programming language that one may do
with any editor, it is dependent on Emacs. There are some other
implementations of Org mode, but it is mostly dependent on Emacs.

Org-LSP implementation that could, at least optionally, read
structured data in a running Emacs instance, or read such data in an
Org file where server resides, then it could eventually provide to its
clients access to more features than commonly expected from LSP, such
as lists of tags, properties, timestamps, including capture templates,
and agenda features. Then if server would be really remote, users
could at least collaborate in the sense that they could work on
similar or same set of structured Org data. They could assign tasks to
same people or have same types of TODO keywords, common LaTeX and PDF
export decorations or other specific settings.

Re: Bring up a screen giving option to open a series of orgmode files

[Jean Louis]

* TRS-80  [2020-12-15 01:29]:
> How to annotate literally everything[0]
> by karlicoss
> 
> There are quite a lot of other very interesting articles there as well
> in the same (and related) veins.  Enjoy!
> 
> Cheers,
> TRS-80
> 
> [0] https://beepb00p.xyz/annotating.html

Excellent, things to research, thank you.

Re: Emacs as an Org LSP server

[Dominik Schrempf]

Hello!

I am infrequent active participant on this list but follow some discussions.
This one I found particularly interesting. I do see both of your points Tim
Cross, and Jean Louis, thank you for your detailed explanations including the
references.

As a user of Emacs and Org mode (and not so much as a developer), I am mostly
interested in an editor that works well with the features and languages I use.
For example, I am writing a lot of Haskell, and the Haskell Language Server
provides excellent development support. The Haskell Language Server is not
developed exclusively by Emacs users. To the contrary, it's probably developed
mostly by non-Emacs users. Would I use Emacs to write Haskell code if I could
not use the Haskell Language Server? I don't know although I love Emacs. (I am
sure I would, but I would be a little disappointed).

More generally, on https://langserver.org/ I found a very good argument for why
we need a specification such as the LSP.

I quote:

The problem: "The Matrix"
   Go   JavaTypeScript  ...
Emacs  X  X X
VimX  X X
VSCode X  X X
...

The solution: Lang[uage] servers and clients
Go X
Java   X
TypeScript X
...

Emacs  X
VimX
VSCode X

I think this is an excellent idea. However, I am not familiar with the legal
aspects mentioned by Jean. So far I had good experiences with language servers.
On the other side, Org mode is Emacs specific, so this argument does not really
apply. Do we want Org mode to stay Emacs specific? I don't know.

Dominik

Jean Louis  writes:

> There is definitely nothing wrong in providing Org language server
> that runs for different editors who could support the LSP protocol, it
> will boost collaboration.
>
> That is pretty much separate subject of the centralization and
> strategies we spoke about.
>
> * Tim Cross  [2020-12-14 23:19]:
>> This is just ill informed nonsense. The LSP is nothing more than a
>> specification. The fact it was initially defined/proposed by Microsoft
>> is completely irrelevant.
>
> I truly wish it would be that simple.
>
> There are many tools and inventions by Microsoft. Some of them appear
> to be free, but all of them are there to contribute to profit
> making. I am not against profit making. But we have to look into the
> tool as having the purpose to contribute to THEIR profit
> making. History of Microsoft is clear. Sorry, I do not share the
> narrowed viewpoint that they will invest so much money "to help other
> free software developers". That it is defined by Microsoft in
> collaboration with others is very relevant there.
>
> First question to clarify is if it is really patented or not. While
> you as user you can download some Rust server software or Java
> software and run server that will work with various editors, somebody
> else may not be able to do so if there is patent on it. That imposes
> freedom obstacles in future.
>
> Does this patent description correspond to the subject:
> https://uspto.report/patent/app/20190149346
>
>> It is NOT server based in the sense you mean. In fact, it is
>> actually precisely what you argue it should be. LSP is simply a
>> "generic definitions how editor could act, and editor could load
>> those generic definitions locally."
>
> I am well aware that you as user may download the piece of software
> and run it as server on your computer and that you wish to distinguish
> how user may not need a remote server. We clarified this
> already.
>
> Corporation will not have use of your personal use, they will promote
> their servers and push people to get hooked and trapped into it. It
> will become questionable if other entities become able to do the same
> if such process is patented.
>
> That it is server based should be undisputable. The whole protocol
> speaks of sparing client's CPU time, so CPU time will be spared when
> process does not run on the same CPU. You can run it now for
> yourself. Sure. But the strategy is visible from their very open
> descriptions. Large company is not interested in those single
> users. Single users had "git" under their control but nobody had
> enough money and power to centralize 50 million developers.
>
> Innocent example is: https://melpa.org/#/lsp-pascal package that
> requires: https://github.com/arjanadriaanse/pascal-language-server
>
> But it is made and designed as a server for third parties to take
> advantage of it one time in future.
>
> https://code.visualstudio.com/api/language-extensions/language-server-extension-guide
>
> If one would like to improve all editors to use centralized
> specifications than that could be done also by providing server-less
> specification that every editor could load and thus function in the
> same way. Then editor developers could make their underlying language
> module that would understand the extension
> specificiation. Then users would just need to import or load the
> general specification something like XML file or similar type of a
> document that 

Re: Bring up a screen giving option to open a series of orgmode files

[TRS-80]

On 2020-12-14 14:08, Jean Louis wrote:

* Ihor Radchenko  [2020-12-14 15:55]:

Jean Louis  writes:

> * Ihor Radchenko  [2020-12-13 03:39]:
>> Jean Louis  writes:
>> hypothes.is
>
> I can install it on VPS which is definitely in plan. Locally I do not
> locally I have dynamic knowledge repository

I am actually just trying hyposes.is now (after you reminded me about
it). For me, the main advantage is not for pdfs, but rather the 
ability

to have pdf-like annotations in web-pages: highlights, comments, etc.
Combined with local ArchiveBox [1] storage, I can get annotations for 
my

local web archive.

[1] https://github.com/ArchiveBox/ArchiveBox


I have seen it, good tool and it makes sense to have one's own archive
as web pages really disappear. You reminded me of so many references
that it helped me streamline my workflows for soon future and new 
projects.



Hypothes.is as online instance is then useful for those online files,
and WWW pages, but the approach of having private archive and then
annotating such is even better. Still the hypothes.is is separate
dynamic knowledge repository for annotations. Different database,
different set of rules but same open hyperdocument project set of
principles. So I better stick to one database, not to two.


We are getting further and further afield from Orgmode discussion,
however I wanted to share the following article with anyone else who
followed this part of the thread all the way to this point:

How to annotate literally everything[0]
by karlicoss

There are quite a lot of other very interesting articles there as well
in the same (and related) veins.  Enjoy!

Cheers,
TRS-80

[0] https://beepb00p.xyz/annotating.html

Re: Emacs as an Org LSP server

[Jean Louis]

There is definitely nothing wrong in providing Org language server
that runs for different editors who could support the LSP protocol, it
will boost collaboration.

That is pretty much separate subject of the centralization and
strategies we spoke about.

* Tim Cross  [2020-12-14 23:19]:
> This is just ill informed nonsense. The LSP is nothing more than a
> specification. The fact it was initially defined/proposed by Microsoft
> is completely irrelevant.

I truly wish it would be that simple. 

There are many tools and inventions by Microsoft. Some of them appear
to be free, but all of them are there to contribute to profit
making. I am not against profit making. But we have to look into the
tool as having the purpose to contribute to THEIR profit
making. History of Microsoft is clear. Sorry, I do not share the
narrowed viewpoint that they will invest so much money "to help other
free software developers". That it is defined by Microsoft in
collaboration with others is very relevant there.

First question to clarify is if it is really patented or not. While
you as user you can download some Rust server software or Java
software and run server that will work with various editors, somebody
else may not be able to do so if there is patent on it. That imposes
freedom obstacles in future.

Does this patent description correspond to the subject:
https://uspto.report/patent/app/20190149346

> It is NOT server based in the sense you mean. In fact, it is
> actually precisely what you argue it should be. LSP is simply a
> "generic definitions how editor could act, and editor could load
> those generic definitions locally."

I am well aware that you as user may download the piece of software
and run it as server on your computer and that you wish to distinguish
how user may not need a remote server. We clarified this
already.

Corporation will not have use of your personal use, they will promote
their servers and push people to get hooked and trapped into it. It
will become questionable if other entities become able to do the same
if such process is patented.

That it is server based should be undisputable. The whole protocol
speaks of sparing client's CPU time, so CPU time will be spared when
process does not run on the same CPU. You can run it now for
yourself. Sure. But the strategy is visible from their very open
descriptions. Large company is not interested in those single
users. Single users had "git" under their control but nobody had
enough money and power to centralize 50 million developers.

Innocent example is: https://melpa.org/#/lsp-pascal package that
requires: https://github.com/arjanadriaanse/pascal-language-server

But it is made and designed as a server for third parties to take
advantage of it one time in future.

https://code.visualstudio.com/api/language-extensions/language-server-extension-guide

If one would like to improve all editors to use centralized
specifications than that could be done also by providing server-less
specification that every editor could load and thus function in the
same way. Then editor developers could make their underlying language
module that would understand the extension
specificiation. Then users would just need to import or load the
general specification something like XML file or similar type of a
document that says how specific programming language would be linted,
completed, highlighted and so on. And all free software editors would
likely comply and adopt that, would that option be popularized.

That option was not popularized and server based model have been
chosen as only so one can take away computing control from people and
gain larger market share.

Microsoft engineers are not stupid to provide a useful tool and in
addition to put money to promote such tool for other editors as there
would be no gain for them in that strategy.

Maybe not everytime user need to use third software to provide
specification for some language, but most of time. I do understand
that language server provides same service to various editors provided
they use LSP protocol. I do understand it can minimize code writing
which is definitely sound and reasonable. It is just our narrow view
on it. Read the patent and wrong me if that patent does not
apply. Read their plans of server based designed and third party
registry and wrong me if it is not so. 

Instead of some larger Emacs Lisp package for specific language mode,
we will load somewhat or considerably shorter Emacs Lisp PLUS the
external software to provide us server to Emacs supporting that
specific software.

Even the server has to be developed, but apparently minimizes efforts
in larger group of editor developers.

- servers can be downloaded currently by users and used on single
  computer. Yet intention of the protocol is not to be used on single
  computer but to take away the CPU time/effort from clients onto the
  server side. The logic for long term strategy is "third party"
  providing a service. They may or may not 

Re: Emacs as an Org LSP server

[Tom Gillespie]

See also. https://lists.gnu.org/archive/html/emacs-devel/2017-04/msg00798.html
and 
https://www.reddit.com/r/emacs/comments/696pv1/rms_supports_language_server_protocol_integration/
for some discussion. Best,
Tom

On Mon, Dec 14, 2020 at 4:31 PM Tim Cross  wrote:
>
>
>
> I am no fan of Microsoft. I have run Linux as my primary desktop since
> 1994. I have been working as a developer since 1988 and have first hand
> experience regarding many of the poor business practices of Microsoft.
> However, I think the LSP is actually a positive imitative and a
> potential benefit to all developers and all editors and development
> tools, both closed and open source. I have outlined some points I think
> are relevant below.
>
> Russell Adams  writes:
>
> > On Tue, Dec 15, 2020 at 01:08:47AM +0800, TEC wrote:
> >>
> >> Jean Louis  writes:
> >>
> >> > [LSP is a evil plot from microsoft]
> >>
> >> I can see that you're overly concerned about Microsoft being able to
> >> somehow exert control over this. It may assuage your concerns to see an
> >> example "technology stack" that Org-LSP could fit into.
> >
> > REST API calls to a remote server as a core part of editing text in
> > your editor isn't concerning? How remote? How would you know? If they
> > use HTTPS could you even see what is sent?
> >
>
> LSP is not restricted to REST. It uses JSON as the message format, but
> can use any form of remote procedure call. It could be REST, it could be
> basic Unix socket interface, it could be some other TCP interface. Any
> interface both sides understand will work.
>
> >> Microsoft has provided a /standard/ that a huge number of editors/IDEs
> >> have adopted with /independent implementations/. At this point there is
> >> /nothing/ M$ could do to interfere with how the above works.
> >
> > Microsoft doesn't make standards that it can't corrupt or take
> > advantage of. See LDAP/AD, HTML extensions, programming language
> > extensions that makes their solutions incompatible with standards.
> >
>
> Yes, Microsoft does have a poor reputation when it comes to standards.
> However, if you consider why they have proposed the LSP and what their
> business model is, it becomes fairly obvious there is no benefit for
> them in changing this specification without good technical reasons.
>
> Microsoft has proposed the LSP because it has the potential to make
> their editors more popular and able to support more languages. They want
> others to implement the LSP server so that they can support the language
> in their editor or development tools with minimal development effort,
> increasing market share and reducing maintenance costs. Nothing unusual
> with that - basic business principal. They won't want to modify or
> change the protocol unnecessarily as that will break their own
> integration with these servers. Their business model relies on
> maintaining the standard they have proposed.
>
> The key point here is that other technologies, including free software
> tools like Emacs, can also benefit from this technology. I'm sure
> Microsoft would prefer to prevent this, but they can't if they want
> others to develop the language server modules.
>
> One of the biggest challenges for editors like Emacs is how to provide
> support for new languages which include all the features people expect
> in a modern editor. Often, it is extremely difficult to provide these
> features without incorporating some form of language parser or compiler.
> this is difficult to do with just Elisp. To try and work around these
> limitations, Emacs has used things like ECLIM to interface with the
> Eclipse editor and leverage off the internal facilities it provides.
> What the LSP does is provide a generic interface definition which works
> in a similar fashion, but is not dependent on an external server like
> Eclipse.
>
> Consider the potential of a future where in addition to defining a new
> language, tools to compile/parse and execute the language the projects
> which develop/maintain that language also provide an LSP server for that
> language. this would mean that in order to use that language in your
> editor, all you need to do is configure your LSP client to communicate
> with that server.
>
> I currently use 4 different LSP servers in my Emacs setup. None of them
> require a web server. They are all just scripts/executables which sit in
> my bin directory. When I open a file in a language which has a LSP
> server, Emacs starts the server and communicates with it to handle
> completion, linting, format hints etc. There is no external network
> connection required, no remote services, no reporting to MS. Even if
> Microsoft changes the specification, it has no impact on my current use.
>
> >> You seem to be focusing on the term "server" in the name. This seems to
> >> be a red herring in this case. In LSP the server is analogous to "emacs
> >> --daemon" and the client to "emacsclient".
> >
> > REST = web server. Using to make JSON requests over what 

Re: Emacs as an Org LSP server

[Tim Cross]

Russell Adams  writes:

> So in summary, why should anyone contribute to exporting our unique
> features to other editors instead of investing that time making Emacs
> better?
>

You cannot know that such an effort won't also benefit Emacs org mode
users. The greater the user base, the greater the pool of ideas for
enhancing and extending the system. Emacs users and developers don't
have a monopoly on good ideas.

At the end of the day this is about volunteer effort and if someone
wants to volunteer to do something, in general, we should support that
effort (with some caveats of course). If anyone doesn't want to support
it, that is also fine. However, once we start to try and control what or
how people volunteer their time, we venture out into dangerous waters.
At the end of the day, success or failure of an imitative will depend on
whether people use it or not. Most original initiatives never actually
see the light of day and some which do can often have benefits which
were not recognised initially. I prefer to encourage ideas and see what
fruit they will bare rather than discourage them before they begin.

--
Tim Cross

Re: Emacs as an Org LSP server

[Tim Cross]

I am no fan of Microsoft. I have run Linux as my primary desktop since
1994. I have been working as a developer since 1988 and have first hand
experience regarding many of the poor business practices of Microsoft.
However, I think the LSP is actually a positive imitative and a
potential benefit to all developers and all editors and development
tools, both closed and open source. I have outlined some points I think
are relevant below.

Russell Adams  writes:

> On Tue, Dec 15, 2020 at 01:08:47AM +0800, TEC wrote:
>>
>> Jean Louis  writes:
>>
>> > [LSP is a evil plot from microsoft]
>>
>> I can see that you're overly concerned about Microsoft being able to
>> somehow exert control over this. It may assuage your concerns to see an
>> example "technology stack" that Org-LSP could fit into.
>
> REST API calls to a remote server as a core part of editing text in
> your editor isn't concerning? How remote? How would you know? If they
> use HTTPS could you even see what is sent?
>

LSP is not restricted to REST. It uses JSON as the message format, but
can use any form of remote procedure call. It could be REST, it could be
basic Unix socket interface, it could be some other TCP interface. Any
interface both sides understand will work.

>> Microsoft has provided a /standard/ that a huge number of editors/IDEs
>> have adopted with /independent implementations/. At this point there is
>> /nothing/ M$ could do to interfere with how the above works.
>
> Microsoft doesn't make standards that it can't corrupt or take
> advantage of. See LDAP/AD, HTML extensions, programming language
> extensions that makes their solutions incompatible with standards.
>

Yes, Microsoft does have a poor reputation when it comes to standards.
However, if you consider why they have proposed the LSP and what their
business model is, it becomes fairly obvious there is no benefit for
them in changing this specification without good technical reasons.

Microsoft has proposed the LSP because it has the potential to make
their editors more popular and able to support more languages. They want
others to implement the LSP server so that they can support the language
in their editor or development tools with minimal development effort,
increasing market share and reducing maintenance costs. Nothing unusual
with that - basic business principal. They won't want to modify or
change the protocol unnecessarily as that will break their own
integration with these servers. Their business model relies on
maintaining the standard they have proposed.

The key point here is that other technologies, including free software
tools like Emacs, can also benefit from this technology. I'm sure
Microsoft would prefer to prevent this, but they can't if they want
others to develop the language server modules.

One of the biggest challenges for editors like Emacs is how to provide
support for new languages which include all the features people expect
in a modern editor. Often, it is extremely difficult to provide these
features without incorporating some form of language parser or compiler.
this is difficult to do with just Elisp. To try and work around these
limitations, Emacs has used things like ECLIM to interface with the
Eclipse editor and leverage off the internal facilities it provides.
What the LSP does is provide a generic interface definition which works
in a similar fashion, but is not dependent on an external server like
Eclipse.

Consider the potential of a future where in addition to defining a new
language, tools to compile/parse and execute the language the projects
which develop/maintain that language also provide an LSP server for that
language. this would mean that in order to use that language in your
editor, all you need to do is configure your LSP client to communicate
with that server.

I currently use 4 different LSP servers in my Emacs setup. None of them
require a web server. They are all just scripts/executables which sit in
my bin directory. When I open a file in a language which has a LSP
server, Emacs starts the server and communicates with it to handle
completion, linting, format hints etc. There is no external network
connection required, no remote services, no reporting to MS. Even if
Microsoft changes the specification, it has no impact on my current use.

>> You seem to be focusing on the term "server" in the name. This seems to
>> be a red herring in this case. In LSP the server is analogous to "emacs
>> --daemon" and the client to "emacsclient".
>
> REST = web server. Using to make JSON requests over what you are
> editing and your editor requiring the ability to send/receive to a
> potential remote web server is a valid concern.
>

Except that isn't how it works. There is no requirement for a web
server and there is no requirement for it to be based on REST. The
message format is JSON, but how these messages are passed between the
editor and the server is not restricted to a HTTP protocol.


> Emacs daemon is a local socket 

Re: wip-cite status question and feedback

[Bruce D'Arcus]

Could Nicholas or Bastien please update on where this stands at this point?

On Wed, Jun 3, 2020 at 10:53 AM Bruce D'Arcus  wrote:
>
> On Wed, Jun 3, 2020 at 10:40 AM Bastien  wrote:
>
> > Hi all,
> >
> > just a quick word in this thread to say that we are in feature freeze
> > for Org core features (ie. everything in org*.el files, + ob.el/ol.el).
> >
> > So let's take the time to discuss this in details for 9.5 (or later,
> > when it's ready.)
>
> What about the question of including citeproc.el and citeproc.org in org 
> proper?
>
> That seems the most immediate practical question, as it would impact what code
> would be (further) developed, and therefore what would need to be tested, etc.
>
> Andras has expressed openness to that, but also questions.
>
> Bruce

Re: Unhealthy Haskell babel

[Bastien]

Hi Lawrence,

Lawrence Bottorff  writes:

> I'm looking into Haskell (latest ghci) again on org-mode. This

Sadly enough, we don't have a maintainer for ob-haskell.el.

Would you be willing to become the maintainer?

Of course, you can always hand it over to someone else when
you want to.  It is just better to have someone than to have
no one.

Best,

-- 
 Bastien

Re: Emacs as an Org LSP server

[Jean Louis]

* Russell Adams  [2020-12-14 22:20]:
  :PROPERTIES:
  :CREATED:  [2020-12-14 Mon 23:18]
  :ID:   a24a5299-11e6-4ecf-a6c5-4622f0d6c28b
  :END:
> On Tue, Dec 15, 2020 at 02:12:43AM +0800, TEC wrote:
> > > [ MS Taint ]
> >
> > I'm a stats student, so if you'll excuse the slightly odd perspective, I
> > see the chance of MS being dodgy as a bayesian process. Previous
> > knowledge creates an informed prior. It does not allow you to make
> > conclusions without examining each instance on a case-by-case basis,
> > only predictions. To do otherwise is to commit the genetic fallacy.
> 
> I don't credit MS as the source of the idea, only a supporter. So
> let's omit MS from the discussion and distill this down.
> 
> Emacs is a unique and amazing editor. Emacs has special features that
> enables truly remarkable data management and text editing in
> Org-mode. Other editors cannot or have not been able to replicate
> these features, or Emacs Org-mode would not be so uniquely
> desirable. Thus if users want to use Org-mode, they should use
> Emacs. It is freely available and like all worthwhile tools Emacs
> takes some time to learn.

There are now other editors using Org slowly slowly, not full. There
exists Org mode for Vim editor. Various Org based tools like Orgzly
for mobile devices have been developed.

https://github.com/jceb/vim-orgmode

Features like outline, TODO/DONE, properties, tags, and various dates
can be implemented by editor macros in other editors.  The very basic
functionality is open for any editor. Finally all those basic tags,
properties, dates can be as well written by hand. Macros are just
handy there.

There is Perl parser for Org:
https://metacpan.org/pod/Org::Parser

If there are parsing engines than most basic features can be
implemented in other editors. 

> If users and programmers for other editors want to try and replicate
> the success and features of Org in their editor, they are welcome to
> do so. However why should I want to actively contribute to that
> effort?

Maybe for compatibility and better collaboration. Observe the basic
structure as such can be definitely written by any editor. Macros
bound to keys can quickly switch TODO/DONE items, insert SCHEDULED,
DEADLINE by using external calendaring tools such as zenity or
question and answer principles, few variables if supported by editor
may hold various properties and tags to be chosen from.

** TODO Headline  :topublish:
   SCHEDULED: <2020-12-14 Mon>
   :PROPERTIES:
   :DESCRIPTION: My first
   :CREATED:  [2020-12-14 Mon 23:18]
   :ID:   d93f73cf-c420-4d4b-b5c8-db53725e26e4
   :END:

Then searching for various properties, tags, TODO/DONE items becomes
easy in any editor. Command line greping or other types of search also
helps to find specific headlines. It need not be necessarily all Emacs
based.

It helps in collaboration. People using various editors can provide
Org type structure and submit their reports or contributions.

> So in summary, why should anyone contribute to exporting our unique
> features to other editors instead of investing that time making Emacs
> better?

When editing files on remote servers not always I have Emacs available
neither I can always install it (at least not as quick). But few handy
macros that one may fetch from WWW server can temporarily serve to
construct basic Org headlines.

Using Emacs on mobile devices is tedious. I do use it but normally
over SSH. Sometimes directly. It is not user friendly on mobile
devices. If there would be Android/LineageOS/Replicant OS editor that
supports macros, I could at least enter some notes with little
structured text for later. Just that I did not find editor with macros.

I use Emacs on mobile devices in console mode. Somebody made Emacs for
Android as GUI, but it is crushing.

In general, it should be useful from Org website to provide macros for
other editors that support macros, as that way more users may come to Emacs as 
well.

Jean

Re: Emacs as an Org LSP server

[Tim Cross]

Jean Louis  writes:

> It may all look nice and shiny. But what you people don't understand
> is that it is Microsoft and deep meaning of Microsoft one can know if
> one researches the history as only so one can see the present and look
> into future. Microsoft never changed its strategies. Language server
> protocol is just another branch of possible strategies to take away
> people's computing. It is matter of advertising and making it popular,
> when all the fish are in the net that is where final result comes, and
> that is to take away people's freedom and computing to centralized
> places.
>

This is just ill informed nonsense. The LSP is nothing more than a
specification. The fact it was initially defined/proposed by Microsoft
is completely irrelevant.

> If Microsoft is really so friendly, then instead of server based
> language service they could provide generic definitions how editor
> could act, and editor could load those generic definitions locally
> without server/client paradigm.
>

It is NOT server based in the sense you mean. In fact, it is actually
precisely what you argue it should be. LSP is simply a "generic definitions how 
editor
could act, and editor could load those generic definitions locally."

There is absolutely nothing intrinsically wrong with a client server
model. This is exactly the same model you use for your all singing and
dancing extension to org based on a postgres database backend (another
client server model). The 'model' doesn't even need to use TCP
networking, you could do it using just Unix sockets.

Have a look at the existing LSP implementations for Emacs. None of them
require an external server. None of them have anything tied to Microsoft
or github at all (apart from downloading the code). None of them even
require an external network connection.

LSP is nothing more than a specification for a program and a client
which defines the interface between the two and what the supported API
should be. Yes, this has a benefit for Microsoft because it means that
it does not have to implement specific support for every possible
language in their editors like VSCode. However, this is also a benefit
for other editors, like Emacs, because it too can take advantage of this
facility because Microsoft has made the protocol public (they had no
choice other than to make it public because they want others to
implement the servers, not Microsoft).

If your going to speak with authority on some subject and claim we don't
understand it, perhaps you should first make sure you have done your own
research and have a basic understanding of what it is rather than making
inaccurate claims based on a misunderstanding of the use of the word
Server and some baseless conspiracy theory.

Org Capture Menu cannot be fully viewed - Results of testing C-n, C-p, C-v

[pietru]

1. Capture Option Selection
===

C-n, C-p, C-v work well and one can go through the capture menu easily.

Below the capture buffer, I am seeing another buffer that is displaying events
from the mouse (triple-mouse-1, down-mouse 5, ...) and keyboard (down up up, 
...)
that ends getting bigger and bigger and bigger.

It is the buffer in which the user  enters the option.  It does get
bigger than one line, finally taking up most of the frame.  And the
user can do nothing about that - that is you cannot drog the mouse
to resize it.  Not being able to resize the window can become a very
big bother when using org-capture.

2. Problem with %^{prompt|default|completion2|completion3...}
=

Consider the following prompt template.  When I select "a", one gets

--- org-carture 
* 7 Via Appia and Catacombs

  Site:
  Investigation: %^{Investigation|...|Historic Background Research Site 
Evaluation or Testing|Systematic Survey Data Recovery or Excavation|Records 
Search or Inventory Checking|Site Stewardship Monitoring|Site 
Stabilization|Heritage Management|Environment Research|Reconnaissance or 
Survey|Methodology, Theory, or Synthesis|Collections 
Research|Consultation|Ethnographic Research|Research Design or Data Recovery 
Plan|Architectural Survey|Ethnohistoric Research|Ground Disturbance 
Monitoring|Geophysical Survey|Archaeological Overview|Bioarchaeological 
Research|Architectural Documentation|Remote Sensing}%?
 org-capture 

If one has available the up and down arrows for traversing through the 
completion list, it is counter-productive
to show the full completion list for Investigation.  The situation becomes even 
more relevant when the completion
list is a long one.

  ("a" "Via Appia and Catacombs" entry
  (file "~/archaeol.org")

"Site: %^{Site|...|
  Domestic Structure or Architectural Complex|
  Resource Extraction or Production|
  Transportation Structure or Features|
  Funerary and Burial Structures or Features|
  Non-Domestic Structures|
  Archaeological Feature|
  Rock Art|
  Water-Related}\n

  Investigation: %^{Investigation|...|
  Historic Background Research Site Evaluation or Testing|
  Systematic Survey Data Recovery or Excavation|"
  Records Search or Inventory Checking|"
  Site Stewardship Monitoring|
  Site Stabilization|
  Heritage Management|
  Environment Research|
  Reconnaissance or Survey|
  Methodology, Theory, or Synthesis|
  Collections Research|
  Consultation|
  Ethnographic Research|
  Research Design or Data Recovery Plan|
  Architectural Survey|
  Ethnohistoric Research|
  Ground Disturbance Monitoring|
  Geophysical Survey|
  Archaeological Overview|
  Bioarchaeological Research|
  Architectural Documentation|
  Remote Sensing}%?\n"

3 Default Completion Prompt
===

When the default consists of a long completion string, the long default is 
printed together with
default itself.  It could be useful to identify the default, however it should 
not be permanently
printed next to the prompt "Investigation [Historic Background Research Site 
Evaluation or Testing]:"

--- org-capture ---
Investigation [Historic Background Research Site Evaluation or Testing]: 
Historic Background Research Site Evaluation or Testing [No Matches]
--- org-capture ---

This is the capture template

 ("a" "Via Appia and Catacombs" entry
  (file "~/02histr/gadmin/archaeol/archaeol.rcl.org")
  "Investigation: %^{Investigation|Historic Background Research Site Evaluation 
or Testing|
  Systematic Survey Data Recovery or Excavation|Systematic Survey Data Recovery 
or Excavation|
  Records Search or Inventory Checking|Site Stewardship Monitoring|Site 
Stabilization|
  Heritage Management|Environment Research|Reconnaissance or 
Survey|Methodology, Theory, or Synthesis|
  Collections Research|Consultation|Ethnographic Research|Research Design or 
Data Recovery Plan|
  Architectural Survey|Ethnohistoric Research|Ground Disturbance 
Monitoring|Geophysical Survey|
  Archaeological Overview|Bioarchaeological Research|Architectural 
Documentation|Remote Sensing}%?\n") )

> Sent: Monday, December 14, 2020 at 1:41 PM
> From: "Marco Wahl" 
> To: pie...@caramail.com
> Cc: "Org-Mode mailing list" 
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> Hi Pietru and all,
>
> > When making a relatively long Org Capture Menu for Archaeological Field 
> > Management,
> > the relevant capture window cannot be scrolled down.  This becomes 
> > particularly
> > problematic with small field laptops.
>
> Thanks for reporting.
>
> I just committed a fix along the lines of the similar exporter-UI and
> the agenda chooser-UI. Now there is at least C-n, C-p, C-v when the
> window is too small for all the items.
>
> Unfortunately these similar UIs are not unified when looking at the code
> base. E.g. I could not find a simple way to add key M-v to 

[Institute field] (was: export to beamer: author and dynamic effects are not exported.)

[Uwe Brauer]

>>> "ESF" == Eric S Fraga  writes:

   > On Monday, 14 Dec 2020 at 17:24, Uwe Brauer wrote:
   >> Sigh, this is so obvious that it did not occur to me. Thanks 

   > Sometimes the easiest solution is actually the last one
   > considered... happens to me constantly with org mode.

I just realised  that beamer allows 

\institute{\texttt{email:o...@mat.ucm.es}}

But this does not get translated when I add to the org file 

#+institute: : o...@mat.ucm.es

Any ideas?


smime.p7s
Description: S/MIME cryptographic signature

Re: TEC: update the new website ML page?

[Russell Adams]

On Tue, Dec 15, 2020 at 02:20:08AM +0800, TEC wrote:
> > Does Worg's landing page updates need to be addressed before we link
> > to it in the header?
>
> I'd like to see it get a little attention along those lines before hand,
> yes :)

Then I defer to your expertise! Though I can help organize and edit
some Worg content, I despair that I cannot make it pretty.

Could you itemize some suggestions for what would make Worg worthy of
a header link? Perhaps others can help address those concerns.

> > Any improvements to Worg will require additional volunteer efforts and
> > will take some time.
>
> As it just so happens, I've previously volunteered ;)

You have, and I respect your efforts! I also wouldn't volunteer you,
you have to do that yourself. ;]

Again I'm happy to help organize and cleanup, but I have no talent for
appearance. If you choose to spend time on it and could use a hand,
let me know.

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options

[Jean Louis]

* Ihor Radchenko  [2020-12-14 15:46]:
> Jean Louis  writes:
> > Do you mean this:
> >
> > ** DONE Objective
> >CLOSED: [2020-12-13 Sun 20:00]
> > *** TODO [#B] Step to do 1
> > *** TODO Step to do 2
> >
> > when org-enforce-todo-dependencies is true I can still say DONE for
> > Objective above. I have mentioned it today already. Maybe it works on
> > your side, it does not work here. Do I do something wrong? I am on
> > development Emacs version and it does not enforce under emacs -Q
...
> I just looked into this more. Most likely you were trying to set this
> variable manually. To take effect, this variable should be set using
> customisation interface, before loading org, or you may need to run M-x
> org-reload.

That was it! Thank you.

> I also find it helpful to combine the objective + a note about concrete
> action to take on the objective. The concrete action helps to get
> started on the objective without drowning myself into thinking (but not
> doing) about all the things I need to do on that objective.

Objectives here on my side also have their description which is meant
more as communication, information and instruction to people doing
it. Other notes that are maybe useful for management, thinkering, that
would rather obstruct execution of single step are not written in
those headings meant for execution.

> Would you mind writing a paragraph or two to improve the "5 TODO Items"
> section of the manual? At least, we can inform people that the ability
> to scatter todo items all around the documents does not mean that it has
> to be done.

That would be nice. But me writing it for many would not be. It is
better to define list of various paradigms of planning by group of
people who are here on mailing list. Then such paradigms may be
mentioned or referenced collaboratively.

While this type of planning correlate to me:
https://en.wikipedia.org/wiki/Project_management#Planning

it may not correlate to many other people. So various types of
planning should be presented in the manual.

1. Scattered method, putting notes, tasks in many various places and
   compensating for it with org-agenda

2. Project management as given on Wikipedia could then advise for this
   model: https://en.wikipedia.org/wiki/Waterfall_model#Model and
   describe such in short with reference to WWW hyperlink and advising
   Org users to define the objectives and next steps to be followed
   only if previous steps have been accomplished. It is natural to
   write notes related to action step together. But to avoid placing
   notes or action steps from different scope in one file. When one
   headline TODO have been accomplished then it is followed by next
   TODO headline. This way the steps are chronologically ordered.

   What do you think of that?

3. Project planning template could be included as laid out here:
   https://en.wikipedia.org/wiki/Project_management#Planning
   but in simpler way with the example Org template for some practical
   product such as "bread" in bakery or "software project".

What do you think?

Jean

Re: Emacs as an Org LSP server

[Russell Adams]

On Tue, Dec 15, 2020 at 02:26:30AM +0800, TEC wrote:
> This simply isn't what's happening here. I'm just starting work on my
> own little project to give non-emacs people a taste of Org's
> capabilities. I didn't think the way I spend my time was such a matter
> of public concern to the Emacs community.

I don't think you're being criticized for how you choose to spend your
time. It's certainly an interesting coding project to try and do. I've
been very impressed with your ability. For instance discussing the
Latex templates you made and your updates to the website. Please don't
think this is a personal beef with you, or dismissive of your talents.

Your original post to the list on this topic was to solicit
collaboration from other Org users regarding making an LSP server for
Org, and that's where the disagreement comes from.

Clearly there are strong opinions over the direction, degrees of
freedom, and potential misuse of LSP as a technology. The issue
regarding MS's involvement in the LSP standard isn't your problem, nor
under your control. I'd suggest you just accidentally stepped into
"it". You clearly have valid reasons to like LSP, and I admire many of
the goals as well. I (and others) appear to disagree with the LSP
project implementation.

>From my other email, I see this thread as discussing whether the Emacs
community supports spending time on competing technologies, or whether
that time is better focused on improving Emacs and Org.

I think the criticism has been to the effect that there are a variety
of reasons not to support spending community time on competing
technologies like LSP without significant consideration. That
additional consideration is likely larger than us both, and could up
being a project level governance concern and even a legal concern.

In summary I'm positive over you doing a proof of concept code to
satisfy yourself, but I share the concerns over it being a larger
project.

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Emacs as an Org LSP server

[Russell Adams]

On Tue, Dec 15, 2020 at 02:12:43AM +0800, TEC wrote:
> > [ MS Taint ]
>
> I'm a stats student, so if you'll excuse the slightly odd perspective, I
> see the chance of MS being dodgy as a bayesian process. Previous
> knowledge creates an informed prior. It does not allow you to make
> conclusions without examining each instance on a case-by-case basis,
> only predictions. To do otherwise is to commit the genetic fallacy.

I don't credit MS as the source of the idea, only a supporter. So
let's omit MS from the discussion and distill this down.

Emacs is a unique and amazing editor. Emacs has special features that
enables truly remarkable data management and text editing in
Org-mode. Other editors cannot or have not been able to replicate
these features, or Emacs Org-mode would not be so uniquely
desirable. Thus if users want to use Org-mode, they should use
Emacs. It is freely available and like all worthwhile tools Emacs
takes some time to learn.

I understand LSP is about editor agnostic support for common
programming languages and editing operations, reducing code
duplication, and improving editing experience in all editors using
LSP.

As someone using and supporting Emacs, why should I care about LSP?
Perhaps if Emacs lacks a decent editing mode for a language then Emacs
could use LSP to provide missing features.

On the other hand if Emacs can provide an LSP to provide our unique
features to other editors which are not Emacs, does that hurt Emacs?

Emacs and Org are volunteer written and maintained. Volunteer time is
scarce and valuable because it is not paid and the pool of qualified
individuals to provide the specialty labor is small. I don't count
myself among that talent pool, however I advocate for the careful
utilization of their attention and try to contribute from the
sideline.

Given volunteer time for Emacs and Org is valuable, why should that
time be spent on technology that could ultimately decrease Emacs
market share? It seems self defeating to contribute to an effort which
could reduce future interest in Emacs, leading to less volunteer time.

If users and programmers for other editors want to try and replicate
the success and features of Org in their editor, they are welcome to
do so. However why should I want to actively contribute to that
effort?

I see it as a choice between choosing to spend our limited time on
maintaining and improving Emacs and Org, or spend time helping other
editors catch up. This is where MS enters, because they will benefit
and I find that strongly unpalatable.

I do understand I'm being protectionist, yet is that wrong? I support
the idea of other open source editors, but we do compete for users. I
expect other editors to be responsible for implementing their own
features.

If we had more volunteers and a surplus of their valuable time, and
Org didn't struggle for time and attention for maintenance and
improvement, perhaps I would be more supportive of collaborative
efforts between editors. Perhaps I could even ignore that evil
monopolists might indirectly profit.

So in summary, why should anyone contribute to exporting our unique
features to other editors instead of investing that time making Emacs
better?

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Bug: org-capture does not work if called from minibuffer [9.4 (9.4-55-g706ba9-elpaplus @ /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20201207/)]

[Jean Louis]

* Omar Antolín Camarena  [2020-12-14 22:03]:
> > Would you be okay with a user-error message like "Cannot call org-capture
> from the minibuffer"?
> 
> Oh, if I'm going to get an error message I don't care which one it is.
> Might as well leave things as they are currently. What I was hoping is that
> you would be able to fix org-capture so that you can also call it from the
> minibuffer, if enable-recursive-minibuffers is set to t.

On my side that works. When it is enabled I get screen for Org capture
and I can do it.

> I like to think that I can call org-capture no matter what I am
> doing, take a quick note or reminder, and go back to whatever it
> was. It is almost like that: I can't interrupt myself if the
> minibuffer is open, but I can in all other cases.

One solution you can use is that you open separate Emacs instance or
Emacs as server that loads org-capture and serves for capturing
things. It may run in background without interrupting your work. It
can then spawn emacsclient to annotate or write the captured note.

Jean

Re: Bring up a screen giving option to open a series of orgmode files

[Jean Louis]

* Ihor Radchenko  [2020-12-14 15:55]:
> Jean Louis  writes:
> 
> > * Ihor Radchenko  [2020-12-13 03:39]:
> >> Jean Louis  writes:
> >> I have hypothes.is installed inside docker container locally. No serious
> >> protection is required in such case (at least, no more than one would
> >> use to protect private files from dangerous software like browsers).
> >
> > I can install it on VPS which is definitely in plan. Locally I do not
> > think so, as locally I have dynamic knowledge repository that may
> > export to Org if necessary or accessed by collaborative group of
> > people. 
> 
> I am actually just trying hyposes.is now (after you reminded me about
> it). For me, the main advantage is not for pdfs, but rather the ability
> to have pdf-like annotations in web-pages: highlights, comments, etc.
> Combined with local ArchiveBox [1] storage, I can get annotations for my
> local web archive.
> 
> [1] https://github.com/ArchiveBox/ArchiveBox

I have seen it, good tool and it makes sense to have one's own archive
as web pages really disappear. You reminded me of so many references
that it helped me streamline my workflows for soon future and new projects.

> >> I am not sure how it is different from using hypothes.is for the same
> >> purpose. Note that hypothes.is uses pdf fingerprinting, so you don't
> >> even need to store pdf on server side. If user can open the pdf
> >> (obtained from you directly, for example), hypothes.is will
> >> automatically show the up-to-date annotations shared via public
> >> hypothes.is instance for that particular user.
> >
> > The difference is that annotation is separate from file, and there is
> > no need for Javascript. Hyperdocument may contain the PDF file and the
> > annotation together, dispatched to somebody, or referenced from WWW
> > page. It is lightweight. HTML file can be very small and speedy
> > loaded. 
> 
> Hypothes.is does not store the file - just file fingerprint and
> information required to identify and annotation positions within the
> file.

OK and not that I meant it stores files. I was rather referring to
collaborative work within a room or distant servers over VPN where
people collaboratively open references to PDF files. Such PDF files
can be stored on a local computer, could be fetched from server, but
not from public server. This is more privacy issue. Hypothes.is as
public online server must have access to files to show the annotation
as that implies that for example those 1300 files here would need to
be placed online where they by their nature do not belong. They could
be placed on a computer within a course room where each student may
access them.

Hypothes.is as online instance is then useful for those online files,
and WWW pages, but the approach of having private archive and then
annotating such is even better. Still the hypothes.is is separate
dynamic knowledge repository for annotations. Different database,
different set of rules but same open hyperdocument project set of
principles. So I better stick to one database, not to two.

And I just guess that hypothes.is could be invoked from hyperlinks to
show annotations even if not stored yet. That would be great feature,
to just provide section of text with few hyperlinks where user may
start to read the annotation and then open the PDF file to see the
context around the annotation.

Jean

Re: LSP is Microsoft's patented protocol - Re: Emacs as an Org LSP server

[Jean Louis]

* TEC  [2020-12-14 21:48]:
> 
> Hi Jean,
> 
> Please read my previous emails before re-iterating the same points.
> 
> LSP is not patented, it's just referenced in a patent about MS's fancy
> remote development extension.

Do you have evidence it is not patented?

A patent need not be implemented fully. What LSP is is described in
that patent I have referenced. I wish it is not patented. Can you
provide reference that disputes the reference I gave you?

Remember, I wish it would not be so.

Jean

Re: LSP is Microsoft's patented protocol - Re: Emacs as an Org LSP server

[TEC]

Hi Jean,

Please read my previous emails before re-iterating the same points.

LSP is not patented, it's just referenced in a patent about MS's fancy
remote development extension.

Jean Louis  writes:

> Enrich it with unencumbered patent-free solutions.

That's what I'm doing :)

--
Timothy.

Re: Bug: org-capture does not work if called from minibuffer [9.4 (9.4-55-g706ba9-elpaplus @ /home/omarantolin/.emacs.d/elpa/org-plus-contrib-20201207/)]

[Omar Antolín Camarena]

> Would you be okay with a user-error message like "Cannot call org-capture
from the minibuffer"?

Oh, if I'm going to get an error message I don't care which one it is.
Might as well leave things as they are currently. What I was hoping is that
you would be able to fix org-capture so that you can also call it from the
minibuffer, if enable-recursive-minibuffers is set to t. I like to think
that I can call org-capture no matter what I am doing, take a quick note or
reminder, and go back to whatever it was. It is almost like that: I can't
interrupt myself if the minibuffer is open, but I can in all other cases.

This is not a big deal, so if it's not easy to fix, just leave it as is.
But if it happens to be easy to do I think it would be worthwhile, so that
org-capture can live up to its reputation of being able to quickly capture
something /no matter what you were doing at the time/!

--
Omar

On Sat, Dec 12, 2020 at 12:32 PM Bastien  wrote:

> Hi Omar,
>
> thanks for reporting this.
>
> Omar Antolín Camarena  writes:
>
> > I have enable-recursive-minibuffers set to t, and just noticed that
> > org-capture does not work if called from the minibuffer.
> >
> > Steps to reproduce:
> >
> > 1. run emacs -Q
> > 2. evaluate (setq enable-recursive-minibuffers t) in the scratch buffer
> > 3. Open the minibuffer, say by using C-x C-f
> > 4. While still in find-file, run M-x org-capture and pick a template (t
> for Task seems to be offered by default).
> >
> > You should get an error message saying "Can't expand minibuffer to
> > full frame".
>
> Would you be okay with a user-error message like
>
>   "Cannot call org-capture from the minibuffer"
>
> ?
>
> --
>  Bastien
>


-- 
Omar Antolín Camarena

Re: Emacs as an Org LSP server

[Bastien]

Hi Jean,

you quoted the GNU Kind Communication Guidelines already in this
list: https://www.gnu.org/philosophy/kind-communication.en.html

May I draw your attention to this specific sentence:

  Rather than trying to have the last word, look for the times when
  there is no need to reply, perhaps because you already made the
  relevant point clear enough.

>From the last 1000 messages, 174 messages come from you and the vast
majority of them are not about fixing bugs or directly providing an
answer, they are about sharing your opinion on something.  Sometimes
it is on-topic, sometimes it is not, it is hard to tell, because your
message tend to be very long.

I strongly suggest you try to think twice about this sentence from
the GKCG before writing.

Thanks,

-- 
 Bastien

Re: Emacs as an Org LSP server

[Jean Louis]

* TEC  [2020-12-14 21:35]:
> 
> Jean Louis  writes:
> 
> > Microsoft have filed patent for LSP languag server protocol:
> > https://uspto.report/patent/app/20190149346
> 
> This isn't a patent for LSP (it's an open standard), this is a patent
> for their Remote Development package:
> https://code.visualstudio.com/docs/remote/remote-overview.

Are you sure? I wish it would be mistake. But then again did you
research USPTO that there is no patent for LSP?

I see there:

0064] Here, it will be appreciated that a base tool (e.g., Tool A,
Tool B, or Tool C) may be a service or other type of function/tool
that is generally common across many or all of the different types of
client applications. For example, in the context of code editing, the
base tools 420 may include a code completion service, a code debugging
service (e.g., a source code error checking tool), a code highlighting
service, a code navigation operation/service, a code colorization
service (e.g., syntax highlighting in which different colors are
applied to the syntax depending on what category a syntax term belongs
to), a code refactoring service (e.g., restructuring code without
altering its behavior), a code hinting service (e.g., code
completion), a source code search tool, a source code control tool,
and/or a lightbulb service (e.g., an icon service that provides an
expanded display of options).

> I guess this criticism may apply to the lsp-mode / eglot packages, but
> neither of those have any relation to me.

Now, apart from those LSP/Microsoft issues, what is your solution? You
wish to provide LSP server based Org editing to various other editors?

Jean

LSP is Microsoft's patented protocol - Re: Emacs as an Org LSP server

[Jean Louis]

* TEC  [2020-12-14 20:24]:
> 
> Jean Louis  writes:
> 
> > [LSP is a evil plot from microsoft]
> 
> Hi Jean,
> 
> I can see that you're overly concerned about Microsoft being able to
> somehow exert control over this. It may assuage your concerns to see an
> example "technology stack" that Org-LSP could fit into.

Not interested in patented processes. Before any Emacs or GNU software
such as Org within Emacs or Emacs or other software start interacting
by using patented protocols one shall consult attorneys of GNU. Once
attorney confirm that it is alright then go ahead.

See:
https://www.gnu.org/philosophy/software-patents.html

and
https://www.gnu.org/philosophy/fighting-software-patents.html

> Microsoft has provided a /standard/ that a huge number of editors/IDEs
> have adopted with /independent implementations/. At this point there is
> /nothing/ M$ could do to interfere with how the above works.

In Emacs world we have Emacs standard. There is no need to rely on
Micro$oft's patented LSP language server protocols. There is so much
more than you think that M$ can interfer with how the above works.

> You seem to be focusing on the term "server" in the name. This seems to
> be a red herring in this case. In LSP the server is analogous to "emacs
> --daemon" and the client to "emacsclient".

Yes? Don't insist on something that is not, I fully understand what it
is. I am talking of bigger picture and giving you references that may
or may not expand your awareness.

> I appreciate your concerns Jean, and am aware of Microsoft's history,
> however I do not believe there is any factual basis for your conclusions
> in this instance.

See the patent
https://uspto.report/patent/app/20190149346

> There is no need to loose sleep over an LSP Server for Org existing :)
> On the contrary, I think it has the potential to ultimately enrich the
> Org community (see previous discussions).

Enrich it with unencumbered patent-free solutions.

Adopting patented technologies in GNU projects shall be verified by
GNU attorneys.

Jean

Re: Emacs as an Org LSP server

[TEC]

Jean Louis  writes:

> Microsoft have filed patent for LSP languag server protocol:
> https://uspto.report/patent/app/20190149346

This isn't a patent for LSP (it's an open standard), this is a patent
for their Remote Development package:
https://code.visualstudio.com/docs/remote/remote-overview.

Rather different.

> Why should Emacs develop and be built on protocol that Microsoft wish
> to protect as their own, to control and use to subjugate population of
> developers?

This simply isn't what's happening here. I'm just starting work on my
own little project to give non-emacs people a taste of Org's
capabilities. I didn't think the way I spend my time was such a matter
of public concern to the Emacs community.

I guess this criticism may apply to the lsp-mode / eglot packages, but
neither of those have any relation to me.

--
Timothy.

Re: Release Org 9.4.2

[Pankaj Jangid]

Bastien  writes:

> I've released Org 9.4.2, a bugfix release.
>
> This version was merged with the emacs-27 branch:

This is the only code that goes into stable branch first and then into
‘master’. Probably we need tweak the process a bit.

Re: Release Org 9.4.2

[Pankaj Jangid]

Bastien  writes:

>>> I've released Org 9.4.2, a bugfix release.
>>>
>>> This version was merged with the emacs-27 branch:
>>
>> This is the only code that goes into stable branch first and then into
>> ‘master’. Probably we need tweak the process a bit.
>
> Sorry, I don't understand your concern here.  What should be done
> differently?

Sorry for not being elaborate. Actually, I had posted serveral days ago
in another thread as well that probably we should consider emacs-master
for the active development of Org.

I like testing Emacs on the trunk and I ‘git pull’ and ‘make bootstrap’
daily and use it without any external packages. This is just to make
sure that any external package is not the cause for what appears to be
an Emacs bug.

I can certainly add latest Org by adding it to the package-archives. But
right now there is no point. I like to be on the bleeding edge. But I
also like to contribute at least by testing the next major release of
Emacs. And I am not sure whether the latest snapshot of Org from
https://orgmode.org/elpa will be part of next major release of Emacs,
whenever that happens.

Org will also benefit from the wider testing if the incremental changes
are part of everyone’s daily build of emacs-master.

In addition to master, we can release versions via GNU ELPA. That way
users won’t have to tweak their package-archives. Core packages should
not require making changes to package-archives.

I know you are overloaded with tasks at present. So I am not asking that
we do these things rightaway. But somewhere down the line Emacs and Org
development must converge.

Hope to see Org 9.4.2 in master soon. :-)

Re: Emacs as an Org LSP server

[Jean Louis]

* Gerry Agbobada  [2020-12-14 20:32]:
> 
> > It may all look nice and shiny. But what you people don't understand
> > is that it is Microsoft and deep meaning of Microsoft one can know if
> > one researches the history as only so one can see the present and look
> > into future. Microsoft never changed its strategies. Language server
> > protocol is just another branch of possible strategies to take away
> > people's computing. It is matter of advertising and making it popular,
> > when all the fish are in the net that is where final result comes, and
> > that is to take away people's freedom and computing to centralized
> > places.
> > 
> > 
> 
> Hello,
> 
> You made is a very clear point about _not_ understanding that
> "server" does not mean "machine controlled by Microsoft". As long as
> you refuse to understand that, it's very hard to discuss seriously
> on the matter. I attached as a picture how I plan to summarize LSP
> to new Doom Emacs users that don't know much about Emacs
> either. Hopefully this will be clear enough and show that :

Well that is your way of understanding what I said, while I never said
that it cannot run locally neither I said that it will be run by
Microsoft, though it probably will if it get popularized.

Microsoft have filed patent for LSP languag server protocol:
https://uspto.report/patent/app/20190149346

Why should Emacs develop and be built on protocol that Microsoft wish
to protect as their own, to control and use to subjugate population of
developers?

Emacs is free software and shall remain far dubious activities of
Microsoft.

You can tell me how everybody can host one's own website, but reality
is that people don't.

Everybody can host one's own code, software, git, packages, but
reality is that people don't and majority look for gratis solutions
online. Corporations take over the control and have to earn money
somehow, so they trap users into their strategies.

Just as git can be decentralized and installed on many various online
servers, it is rather not and it is centralized on Github mostly that
further traps developers by their proprietary eye candies. In general
Github/Microsoft take away specific control and freedom 0 from users
to run the software as they wish:
https://sanctum.geek.nz/why-not-github.html

When such tool that takes away computing becomes popular by marketing
and advertising it will be definitely offered by largest corporations,
which in turn will trap developers in future to their online tools and
online server side computing, it opens plethora of future privacy
issues, centralization and control from entities like Microsoft and
others.

It really does not matter that it is all nicely packed into marketing
pitch about "open source" and "helpful to developers" and that it is
now not centralized and that people find it good. Marketing from those
corporations created that environment of acceptance that computing may
be taken away.

Their marketing pushes that people adopt LSP as from God granted. And
people currently do not see that flying to the source of light will
not let all flies survive.

Microsoft NEVER does any move in the public without having clearly
defined strategy on how to gain control over people's computing.

Jean

See the future.

Re: TEC: update the new website ML page?

[TEC]

Russell Adams  writes:

>> I do see your point. I think in order to warrant being presented as a
>> one-step-from-the-homepage target it would be good to tidy up the Worg
>> homepage.
>
> That's a valid criticism. Worg's main page could use an update to look
> more like the main site.
>
> Does Worg's landing page updates need to be addressed before we link
> to it in the header?

I'd like to see it get a little attention along those lines before hand,
yes :)

> Any improvements to Worg will require additional volunteer efforts and
> will take some time.

As it just so happens, I've previously volunteered ;)

All the best,

Timothy.

Re: Emacs as an Org LSP server

[TEC]

Russell Adams  writes:

> REST API calls to a remote server as a core part of editing text in
> your editor isn't concerning? How remote? How would you know? If they
> use HTTPS could you even see what is sent?

I'm not concerned about REST API calls to a remote server, because:
1. There are no REST API calls
2. There is no remote server

> Microsoft doesn't make standards that it can't corrupt or take
> advantage of. See LDAP/AD, HTML extensions, programming language
> extensions that makes their solutions incompatible with standards.

Sure, but I can choose not to support a certain standard, as can other
LSP-Client/Server FLOSS devs, and you can install a particular version
of either.


> REST = web server. Using to make JSON requests over what you are
> editing and your editor requiring the ability to send/receive to a
> potential remote web server is a valid concern.

No REST, just JSON-RPC, which is just a data format. I don't think JSON
is evil. Oh, and once again, no web servers.

> Emacs daemon is a local socket interface (by default) for
> communication between processes on the same box.

Yep, like LSP. Hence the analogy.

> [ MS Taint ]

I'm a stats student, so if you'll excuse the slightly odd perspective, I
see the chance of MS being dodgy as a bayesian process. Previous
knowledge creates an informed prior. It does not allow you to make
conclusions without examining each instance on a case-by-case basis,
only predictions. To do otherwise is to commit the genetic fallacy.

--
Timothy

Re: TEC: update the new website ML page?

[Russell Adams]

On Tue, Dec 15, 2020 at 12:29:06AM +0800, TEC wrote:
>
> > However Worg is a key component because it's community maintained
> > documentation. Not just anyone can upload to the main site, but Worg
> > is as "wiki" as we have. As an integral part of the community
> > supported documentation I thought it should be in the header.
>
> I do see your point. I think in order to warrant being presented as a
> one-step-from-the-homepage target it would be good to tidy up the Worg
> homepage.

That's a valid criticism. Worg's main page could use an update to look
more like the main site.

Does Worg's landing page updates need to be addressed before we link
to it in the header?

Any improvements to Worg will require additional volunteer efforts and
will take some time.

Not linking it as an important part of the Org site could contribute
to continued inattention.

I leave it up to you. I value your work revamping the main site, and
you are clearly much more skilled in HTML presentation of information
than I.

Thanks.


--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Emacs as an Org LSP server

[TEC]

Hi Neil,



Nope! That’s the nice thing, those are all currently features of the LSP
protocol .




All the best,Timothy




From: ">Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: ">TEC
Cc: "org-mode-email" 
Date: Tue, 15 Dec 2020 01:57:27 +0800
Yes, thanks, I'm seeing the picture now.  I guess that some of those things would require extensions to the LSP standard/protocol, as well as just implementation, wouldn't they?On Mon, 14 Dec 2020 at 17:31, TEC  wrote:

Hi Neil,



Ah, I see what you’re getting at now. I’ll try to give you an idea of what I
think could apply.


Provide nice text manipulation actions, e.g. structural editing
Completion, with company
Org Export
Run Babel blocks
Org syntax highlighting (potentially)
Folding (maybe)
All the nice stuff like table alignment, checkbox state propagation…

Does that help?




All the best,Timothy




From: Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: TEC
Cc: "org-mode-email" 
Date: Tue, 15 Dec 2020 01:22:55 +0800
I'm afraid things still aren't clear for me.  Is there a reason it's so hard to give a concrete example?If I try to analogise from how LSP works for golang, I believe the LSP server does things like- complete symbol beginning with "Xyz"- tell me where so-and-so function is defined (e.g. so that the client editor can jump to it).I'm not sure if operations like that make sense for Org.Another possibility might be interacting, from a 3rd party editor, with a body of Org content that has been primarily written and managed in Emacs.  If so, what would those interactions be?  Marking a task as done?  Something more complex than that?Or is it like: 3rd party editor opens an Org file and the user types some .  Editor asks the LSP server (Emacs) "what does  mean?", and the server replies "it means the Org entry should now look like this: ..."On Mon, 14 Dec 2020 at 15:58, TEC  wrote:

Hi Neil,



Good to hear that you did take a look at the readme .



You can think of the LSP as a specification for cross-editor/IDE extensions. The
intent of this is to make some of Org’s functionality accessible to the ~95% of
people who don’t use Emacs, by hooking into Emacs itself.



Does that clear things up for you? You can also see https://langserver.org/.




All the best,Timothy




From: Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: TEC
Cc: "org-mode-email" 
Date: Mon, 14 Dec 2020 23:46:12 +0800
Thanks Timothy.  I did read the README, but I'm afraid I still can't quite picture a specific use.On Mon, 14 Dec 2020 at 15:28, TEC  wrote:

Hi Neil,



I’m going to quote you the readme from the linked github repo:



Allow the unwashed masses to use Org, without using Emacs, using Emacs.




Here’s the image from the readme



And here’s the first line from the first result of a google search for ”:



The Language Server Protocol (LSP) defines the protocol used between an editor
or IDE and a language server that provides language features like auto complete,
go to definition, find all references etc.




That should give you an idea of the intent here.




All the best,Timothy




From: Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: TEC
Cc: "org-mode-email" 
Date: Mon, 14 Dec 2020 19:41:05 +0800
Could you describe a use case?  Apologies if I missed this in earlier threads.On Sun, 13 Dec 2020 at 10:44, TEC  wrote:
A little progress update.https://github.com/tecosaur/org-lsp now exists.
I have no idea what I'm doing, so if anyone has feedback on the current
idea, that would be much appreciated.
TEC  writes:
> Hi Everyone,
>
> From the Org standardisation effort the idea of using Emacs as the basis
> of an LSP server for Org has been mentioned a few times.
>
> I thought this deserved it's own thread so here it is :)
>
> I'm quite keen to investigate the viability of this idea.
> Some key questions that I think need addressing are:
> 1. How can we 'package' Emacs into an LSP client?
> 2. Assuming we use some language as the basis for the host how do  we
>    want to pick it? LSP library? Lisp? Are there any outstanding
>    contenders.
> 3. How much effort is involved? Is it worth it to try to make Org  more
>    approachable* (without Emacs)?
>
> Lastly, but perhaps even more crucially --- who would be interested in
> working on this? I certainly am, but this feels like something that
> would be more viable with a small working group.
>
> Who's interested?
>
> Timothy.
>
>
> * I can't help but think that this hypothetical LSP server may   serve as
>  a 'gateway drug' to Org in Emacs 

Re: Emacs as an Org LSP server

[Russell Adams]

On Tue, Dec 15, 2020 at 01:08:47AM +0800, TEC wrote:
>
> Jean Louis  writes:
>
> > [LSP is a evil plot from microsoft]
>
> I can see that you're overly concerned about Microsoft being able to
> somehow exert control over this. It may assuage your concerns to see an
> example "technology stack" that Org-LSP could fit into.

REST API calls to a remote server as a core part of editing text in
your editor isn't concerning? How remote? How would you know? If they
use HTTPS could you even see what is sent?

> Microsoft has provided a /standard/ that a huge number of editors/IDEs
> have adopted with /independent implementations/. At this point there is
> /nothing/ M$ could do to interfere with how the above works.

Microsoft doesn't make standards that it can't corrupt or take
advantage of. See LDAP/AD, HTML extensions, programming language
extensions that makes their solutions incompatible with standards.

> You seem to be focusing on the term "server" in the name. This seems to
> be a red herring in this case. In LSP the server is analogous to "emacs
> --daemon" and the client to "emacsclient".

REST = web server. Using to make JSON requests over what you are
editing and your editor requiring the ability to send/receive to a
potential remote web server is a valid concern.

Emacs daemon is a local socket interface (by default) for
communication between processes on the same box.

> I appreciate your concerns Jean, and am aware of Microsoft's history,
> however I do not believe there is any factual basis for your conclusions
> in this instance.

Tainted, definitions quoted from https://www.thefreedictionary.com/tainted

 - To affect or associate with something undesirable or reprehensible:
a reputation that was tainted by allegations of illegal activity.

 - An undesirable or corrupting influence or association: wanted to
avoid the taint of an accounting scandal.

This is the point. Given Microsoft's shameful history, any project
they are supporting is *tainted* by their corrupting influence and
association. That LSP is pushed by MS makes it undesirable due to
their reputation. That Github is now owned by MS makes it tainted by
their reputation.

Companies, just like individuals should be judged by their actions.
Microsoft's well earned poor reputation is sufficient reason to
exclude them from any open source effort.

I must conclude that MS is supporting LSP because they believe it will
increase market share for their proprietary editors. This is due to
their reputation and historic behavior. Thus I have no desire to
support LSP and thus not support MS indirectly.

You might be tired of this kind of debate, but imagine how those of us
who have been in IT for 20 or 30 years are tired of being told that
the abuse we have repeatedly endured from MS is somehow no longer
relevant. That somehow we're wrong to point out we have suffered abuse
from a technology monopoly, and that we are weary and intolerant of
those enabling it (ie: govts, CIOs, end users with fancy toys).

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Agenda clock-report-mode doesn't observe agenda filters

[Tory S. Anderson]

I love org-agenda-clockreport-mode . However, I have several files that include 
my work projects, and they all have my :WORK: tag on them. I want to get the 
number of hours put into :WORK: for the period and understand that the way is 
supposed to be to just filter my agenda view to be what I am interested in, 
then look at the associated clockreport at the bottom. However, the clockreport 
seems to always calculate everything, regardless of my agenda filters (showing 
time results for things NOT showing with my current filters). Looks like a bug, 
unless I misunderstood something.

- Tory

Re: Emacs as an Org LSP server

[TEC]

Russell Adams  writes:

> LSP is also REST based, so your editor how has to talk to a web
> *server* over a network. This could be central, and not just on your
> machine. How would you know in an update that didn't happen?

This just ... isn't right.
It's not even REST based, it's using JSON-RPC, and most servers use
stdout + stdin. I'm afraid this simply isn't accurate.


I'm going to ignore the genetic fallacy re: Microsoft.

> I'm not interested in spending any time improving an LSP for Org which
> would give non-free editors additional functionality with Org files.

Because I feel that the rest of the points have been addressed, I'll
just cover this. Looking at https://langserver.org/, the list of current
editors that have LSP clients is:

- Acme
- PROPRIETRY! C++ Builder
- PROPRIETRY! Delphi
- Eclipse
- Eclipse Che
- Emacs (x2)
- GNATStudio
- PROPRIETRY! IntelliJ
- Kakoune
- Kate
- Moonshine IDE
- Oni
- VSCode
- NeoVim (x5)
- PROPRIETRY! Sublime Text 3
- Atom
- CodeMirror
- Theia
- Spyder IDE
- Qt Creator
- Ycmd
- Brackets
- JupyterLab

Note that the majority of the above, (and if considering usage: vast
majority), are *free*.

If your issue is that there is the potential for some non-free
applications to also benefit from this ... the logical conclusion is
that we should stop using the GPL licence, because it allows *anyone*
(including non-free applications) to benefit --- thus inherently making
the work itself /less/ free .

--
Timothy.

Re: Emacs as an Org LSP server

[Neil Jerram]

Yes, thanks, I'm seeing the picture now.  I guess that some of those things
would require extensions to the LSP standard/protocol, as well as just
implementation, wouldn't they?

On Mon, 14 Dec 2020 at 17:31, TEC  wrote:

> Hi Neil,
>
> Ah, I see what you’re getting at now. I’ll try to give you an idea of what
> I think could apply.
>
>- Provide nice text manipulation actions, e.g. structural editing
>- Completion, with company
>- Org Export
>- Run Babel blocks
>- Org syntax highlighting (potentially)
>- Folding (maybe)
>- All the nice stuff like table alignment, checkbox state propagation…
>
> Does that help?
>
> All the best,
> *Timothy*
>
> * From*: Neil Jerram <%22neil+jerram%22+%3cneiljer...@gmail.com%3E>
> * Subject*: Re: Emacs as an Org LSP server
> * To*: TEC <%22tec%22+%3ctecos...@gmail.com%3E>
> * Cc*: "org-mode-email" 
> * Date*: Tue, 15 Dec 2020 01:22:55 +0800
> I'm afraid things still aren't clear for me.  Is there a reason it's so
> hard to give a concrete example?
>
> If I try to analogise from how LSP works for golang, I believe the LSP
> server does things like
> - complete symbol beginning with "Xyz"
> - tell me where so-and-so function is defined (e.g. so that the client
> editor can jump to it).
> I'm not sure if operations like that make sense for Org.
>
> Another possibility might be interacting, from a 3rd party editor, with a
> body of Org content that has been primarily written and managed in Emacs.
> If so, what would those interactions be?  Marking a task as done?
> Something more complex than that?
>
> Or is it like: 3rd party editor opens an Org file and the user types some
> .  Editor asks the LSP server (Emacs) "what does
>  mean?", and the server replies "it means the Org
> entry should now look like this: ..."
>
>
> On Mon, 14 Dec 2020 at 15:58, TEC  wrote:
>
>> Hi Neil,
>>
>> Good to hear that you did take a look at the readme .
>>
>> You can think of the LSP as a specification for cross-editor/IDE
>> extensions. The intent of this is to make some of Org’s functionality
>> accessible to the ~95% of people who don’t use Emacs, by hooking into Emacs
>> itself.
>>
>> Does that clear things up for you? You can also see
>> https://langserver.org/.
>>
>> All the best,
>> *Timothy*
>>
>> * From*: Neil Jerram <%22neil+jerram%22+%3cneiljer...@gmail.com%3E>
>> * Subject*: Re: Emacs as an Org LSP server
>> * To*: TEC <%22tec%22+%3ctecos...@gmail.com%3E>
>> * Cc*: "org-mode-email" 
>> * Date*: Mon, 14 Dec 2020 23:46:12 +0800
>> Thanks Timothy.  I did read the README, but I'm afraid I still can't
>> quite picture a specific use.
>>
>>
>> On Mon, 14 Dec 2020 at 15:28, TEC  wrote:
>>
>>> Hi Neil,
>>>
>>> I’m going to quote you the readme from the linked github repo:
>>>
>>> Allow the unwashed masses to use Org, without using Emacs, using Emacs.
>>>
>>> Here’s the image from the readme [image: model.png]
>>>
>>> And here’s the first line from the first result of a google search for
>>> ”:
>>>
>>> The Language Server Protocol (LSP) defines the protocol used between an
>>> editor or IDE and a language server that provides language features
>>> like auto complete, go to definition, find all references etc.
>>>
>>> That should give you an idea of the intent here.
>>>
>>> All the best,
>>> *Timothy*
>>>
>>> * From*: Neil Jerram <%22neil+jerram%22+%3cneiljer...@gmail.com%3E>
>>> * Subject*: Re: Emacs as an Org LSP server
>>> * To*: TEC <%22tec%22+%3ctecos...@gmail.com%3E>
>>> * Cc*: "org-mode-email" 
>>> * Date*: Mon, 14 Dec 2020 19:41:05 +0800
>>> Could you describe a use case?  Apologies if I missed this in earlier
>>> threads.
>>>
>>>
>>> On Sun, 13 Dec 2020 at 10:44, TEC  wrote:
>>>

 A little progress update.

 https://github.com/tecosaur/org-lsp now exists.

 I have no idea what I'm doing, so if anyone has feedback on the current
 idea, that would be much appreciated.

 TEC  writes:

 > Hi Everyone,
 >
 > From the Org standardisation effort the idea of using Emacs as the
 basis
 > of an LSP server for Org has been mentioned a few times.
 >
 > I thought this deserved it's own thread so here it is :)
 >
 > I'm quite keen to investigate the viability of this idea.
 > Some key questions that I think need addressing are:
 > 1. How can we 'package' Emacs into an LSP client?
 > 2. Assuming we use some language as the basis for the host how do  we
 >want to pick it? LSP library? Lisp? Are there any outstanding
 >contenders.
 > 3. How much effort is involved? Is it worth it to try to make Org
 more
 >approachable* (without Emacs)?
 >
 > Lastly, but perhaps even more crucially --- who would be interested in
 > working on this? I certainly am, but this feels like something that
 > would be more viable with a small working group.
 >
 > Who's interested?
 >
 > Timothy.
 >
 >
 > * I can't help but think that 

Re: Emacs as an Org LSP server

[TEC]

Hi Neil,



Ah, I see what you’re getting at now. I’ll try to give you an idea of what I
think could apply.


Provide nice text manipulation actions, e.g. structural editing
Completion, with company
Org Export
Run Babel blocks
Org syntax highlighting (potentially)
Folding (maybe)
All the nice stuff like table alignment, checkbox state propagation…

Does that help?




All the best,Timothy




From: ">Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: ">TEC
Cc: "org-mode-email" 
Date: Tue, 15 Dec 2020 01:22:55 +0800
I'm afraid things still aren't clear for me.  Is there a reason it's so hard to give a concrete example?If I try to analogise from how LSP works for golang, I believe the LSP server does things like- complete symbol beginning with "Xyz"- tell me where so-and-so function is defined (e.g. so that the client editor can jump to it).I'm not sure if operations like that make sense for Org.Another possibility might be interacting, from a 3rd party editor, with a body of Org content that has been primarily written and managed in Emacs.  If so, what would those interactions be?  Marking a task as done?  Something more complex than that?Or is it like: 3rd party editor opens an Org file and the user types some .  Editor asks the LSP server (Emacs) "what does  mean?", and the server replies "it means the Org entry should now look like this: ..."On Mon, 14 Dec 2020 at 15:58, TEC  wrote:

Hi Neil,



Good to hear that you did take a look at the readme .



You can think of the LSP as a specification for cross-editor/IDE extensions. The
intent of this is to make some of Org’s functionality accessible to the ~95% of
people who don’t use Emacs, by hooking into Emacs itself.



Does that clear things up for you? You can also see https://langserver.org/.




All the best,Timothy




From: Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: TEC
Cc: "org-mode-email" 
Date: Mon, 14 Dec 2020 23:46:12 +0800
Thanks Timothy.  I did read the README, but I'm afraid I still can't quite picture a specific use.On Mon, 14 Dec 2020 at 15:28, TEC  wrote:

Hi Neil,



I’m going to quote you the readme from the linked github repo:



Allow the unwashed masses to use Org, without using Emacs, using Emacs.




Here’s the image from the readme



And here’s the first line from the first result of a google search for ”:



The Language Server Protocol (LSP) defines the protocol used between an editor
or IDE and a language server that provides language features like auto complete,
go to definition, find all references etc.




That should give you an idea of the intent here.




All the best,Timothy




From: Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: TEC
Cc: "org-mode-email" 
Date: Mon, 14 Dec 2020 19:41:05 +0800
Could you describe a use case?  Apologies if I missed this in earlier threads.On Sun, 13 Dec 2020 at 10:44, TEC  wrote:
A little progress update.https://github.com/tecosaur/org-lsp now exists.
I have no idea what I'm doing, so if anyone has feedback on the current
idea, that would be much appreciated.
TEC  writes:
> Hi Everyone,
>
> From the Org standardisation effort the idea of using Emacs as the basis
> of an LSP server for Org has been mentioned a few times.
>
> I thought this deserved it's own thread so here it is :)
>
> I'm quite keen to investigate the viability of this idea.
> Some key questions that I think need addressing are:
> 1. How can we 'package' Emacs into an LSP client?
> 2. Assuming we use some language as the basis for the host how do  we
>    want to pick it? LSP library? Lisp? Are there any outstanding
>    contenders.
> 3. How much effort is involved? Is it worth it to try to make Org  more
>    approachable* (without Emacs)?
>
> Lastly, but perhaps even more crucially --- who would be interested in
> working on this? I certainly am, but this feels like something that
> would be more viable with a small working group.
>
> Who's interested?
>
> Timothy.
>
>
> * I can't help but think that this hypothetical LSP server may   serve as
>  a 'gateway drug' to Org in Emacs 

Re: Emacs as an Org LSP server

[Russell Adams]

On Mon, Dec 14, 2020 at 05:22:55PM +, Neil Jerram wrote:
> If I try to analogise from how LSP works for golang, I believe the LSP
> server does things like
> - complete symbol beginning with "Xyz"
> - tell me where so-and-so function is defined (e.g. so that the client
> editor can jump to it).
> I'm not sure if operations like that make sense for Org.

LSP is also REST based, so your editor how has to talk to a web
*server* over a network. This could be central, and not just on your
machine. How would you know in an update that didn't happen?

> Another possibility might be interacting, from a 3rd party editor, with a
> body of Org content that has been primarily written and managed in Emacs.
> If so, what would those interactions be?  Marking a task as done?
> Something more complex than that?

I'm not interested in spending any time improving an LSP for Org which
would give non-free editors additional functionality with Org files.

That Microsoft is involved in the LSP specification seals the deal for
me.

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Emacs as an Org LSP server

[TEC]

Jean Louis  writes:

> [LSP is a evil plot from microsoft]

Hi Jean,

I can see that you're overly concerned about Microsoft being able to
somehow exert control over this. It may assuage your concerns to see an
example "technology stack" that Org-LSP could fit into.

1. Org / Emacs, all GPL-3
2. Rust LSP server + Rust cargo extensions, none of which are written by M$ 
(all GPL-compatable)
3. Kakoune LSP = Rust, using the "unlicence" licence
4. Kakoune (an experimental text editor, with /no/ relation to M$)

Microsoft has provided a /standard/ that a huge number of editors/IDEs
have adopted with /independent implementations/. At this point there is
/nothing/ M$ could do to interfere with how the above works.

You seem to be focusing on the term "server" in the name. This seems to
be a red herring in this case. In LSP the server is analogous to "emacs
--daemon" and the client to "emacsclient".

I appreciate your concerns Jean, and am aware of Microsoft's history,
however I do not believe there is any factual basis for your conclusions
in this instance.

There is no need to loose sleep over an LSP Server for Org existing :)
On the contrary, I think it has the potential to ultimately enrich the
Org community (see previous discussions).

--
Timothy.

Re: Emacs as an Org LSP server

[Neil Jerram]

I'm afraid things still aren't clear for me.  Is there a reason it's so
hard to give a concrete example?

If I try to analogise from how LSP works for golang, I believe the LSP
server does things like
- complete symbol beginning with "Xyz"
- tell me where so-and-so function is defined (e.g. so that the client
editor can jump to it).
I'm not sure if operations like that make sense for Org.

Another possibility might be interacting, from a 3rd party editor, with a
body of Org content that has been primarily written and managed in Emacs.
If so, what would those interactions be?  Marking a task as done?
Something more complex than that?

Or is it like: 3rd party editor opens an Org file and the user types some
.  Editor asks the LSP server (Emacs) "what does
 mean?", and the server replies "it means the Org
entry should now look like this: ..."


On Mon, 14 Dec 2020 at 15:58, TEC  wrote:

> Hi Neil,
>
> Good to hear that you did take a look at the readme .
>
> You can think of the LSP as a specification for cross-editor/IDE
> extensions. The intent of this is to make some of Org’s functionality
> accessible to the ~95% of people who don’t use Emacs, by hooking into Emacs
> itself.
>
> Does that clear things up for you? You can also see
> https://langserver.org/.
>
> All the best,
> *Timothy*
>
> * From*: Neil Jerram <%22neil+jerram%22+%3cneiljer...@gmail.com%3E>
> * Subject*: Re: Emacs as an Org LSP server
> * To*: TEC <%22tec%22+%3ctecos...@gmail.com%3E>
> * Cc*: "org-mode-email" 
> * Date*: Mon, 14 Dec 2020 23:46:12 +0800
> Thanks Timothy.  I did read the README, but I'm afraid I still can't quite
> picture a specific use.
>
>
> On Mon, 14 Dec 2020 at 15:28, TEC  wrote:
>
>> Hi Neil,
>>
>> I’m going to quote you the readme from the linked github repo:
>>
>> Allow the unwashed masses to use Org, without using Emacs, using Emacs.
>>
>> Here’s the image from the readme [image: model.png]
>>
>> And here’s the first line from the first result of a google search for
>> ”:
>>
>> The Language Server Protocol (LSP) defines the protocol used between an
>> editor or IDE and a language server that provides language features like
>> auto complete, go to definition, find all references etc.
>>
>> That should give you an idea of the intent here.
>>
>> All the best,
>> *Timothy*
>>
>> * From*: Neil Jerram <%22neil+jerram%22+%3cneiljer...@gmail.com%3E>
>> * Subject*: Re: Emacs as an Org LSP server
>> * To*: TEC <%22tec%22+%3ctecos...@gmail.com%3E>
>> * Cc*: "org-mode-email" 
>> * Date*: Mon, 14 Dec 2020 19:41:05 +0800
>> Could you describe a use case?  Apologies if I missed this in earlier
>> threads.
>>
>>
>> On Sun, 13 Dec 2020 at 10:44, TEC  wrote:
>>
>>>
>>> A little progress update.
>>>
>>> https://github.com/tecosaur/org-lsp now exists.
>>>
>>> I have no idea what I'm doing, so if anyone has feedback on the current
>>> idea, that would be much appreciated.
>>>
>>> TEC  writes:
>>>
>>> > Hi Everyone,
>>> >
>>> > From the Org standardisation effort the idea of using Emacs as the
>>> basis
>>> > of an LSP server for Org has been mentioned a few times.
>>> >
>>> > I thought this deserved it's own thread so here it is :)
>>> >
>>> > I'm quite keen to investigate the viability of this idea.
>>> > Some key questions that I think need addressing are:
>>> > 1. How can we 'package' Emacs into an LSP client?
>>> > 2. Assuming we use some language as the basis for the host how do  we
>>> >want to pick it? LSP library? Lisp? Are there any outstanding
>>> >contenders.
>>> > 3. How much effort is involved? Is it worth it to try to make Org  more
>>> >approachable* (without Emacs)?
>>> >
>>> > Lastly, but perhaps even more crucially --- who would be interested in
>>> > working on this? I certainly am, but this feels like something that
>>> > would be more viable with a small working group.
>>> >
>>> > Who's interested?
>>> >
>>> > Timothy.
>>> >
>>> >
>>> > * I can't help but think that this hypothetical LSP server may   serve
>>> as
>>> >  a 'gateway drug' to Org in Emacs 
>>>
>>>
>>>

Re: Emacs as an Org LSP server

[Jean Louis]

It may all look nice and shiny. But what you people don't understand
is that it is Microsoft and deep meaning of Microsoft one can know if
one researches the history as only so one can see the present and look
into future. Microsoft never changed its strategies. Language server
protocol is just another branch of possible strategies to take away
people's computing. It is matter of advertising and making it popular,
when all the fish are in the net that is where final result comes, and
that is to take away people's freedom and computing to centralized
places.

If Microsoft is really so friendly, then instead of server based
language service they could provide generic definitions how editor
could act, and editor could load those generic definitions locally
without server/client paradigm.

Now Emacs, as prime tool of the GNU project, as free software, is then
supposed to communicate with something external to receive information
on how to do its functions? One big LOL on that!

What will be next? Maybe computers without hard disks that simply load
all they need from Microsoft.

Let us give away our computing to Microsoft.

What people do not understand is that large and evil corporation such
as Microsoft never does any move without strategic planning and
without objective. Try to recognize patterns.

Then better right away stop developing language packages for Emacs and
give away computing to corporations.

Jean

Re: TEC: update the new website ML page?

[TEC]

Russell Adams  writes:

> One could argue that "Releases", "Updates", and "Install" should be
> merged into a common download link. They all are the same thing. ;]

Hmmm. "Updates" seems like a bit of a special thing, but perhaps some
merging could happen sensibly. If that could be worked out, I'd
definitely be much more receptive to the idea of adding another link.

> I completely agree with you that not everything can live in the
> header.

Oh good :)

> However Worg is a key component because it's community maintained
> documentation. Not just anyone can upload to the main site, but Worg
> is as "wiki" as we have. As an integral part of the community
> supported documentation I thought it should be in the header.

I do see your point. I think in order to warrant being presented as a
one-step-from-the-homepage target it would be good to tidy up the Worg
homepage.

At the moment I suspect it would be a bit overwhelming to newcomers ---
everything splurged onto on page seems a bit much :P

How does that sound?

Timothy.

insert file, relative or absolute path when using

[Uwe Brauer]

Hi

I use tempo template and writing 

Re: export to beamer: author and dynamic effects are not exported.

[Eric S Fraga]

On Monday, 14 Dec 2020 at 17:24, Uwe Brauer wrote:
> Sigh, this is so obvious that it did not occur to me. Thanks 

Sometimes the easiest solution is actually the last one
considered... happens to me constantly with org mode.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-160-g7c8dce

Re: TEC: update the new website ML page?

[Russell Adams]

On Mon, Dec 14, 2020 at 11:37:09PM +0800, TEC wrote:
> Hi Russel, while I appreciate the significance of Worg, I currently
> don't feel that adding it to the header improves the site.
>
> There are two concerns I have on this.
>
> 1. I'm very wary of "header creep", see https://0x0.st/iFS7.png for a
>mock up of an "extreme" example.
>IMO the current state is "bulging", with 4-6 items as the ideal.
>Adding Worg would take us to 8. In addition to the increased number
>of visual elements, it also lessens the individual significance of
>the per-existing items. If a "features" item has 3 other items, it is
>much more emphasised than when it has 7 other items.
>
>This is just a long winded way of me expressing the view that adding
>to the header affects the perception of the rest of the header, and
>thus the overall effect may be negative, as I suspect it would be in
>this case.

One could argue that "Releases", "Updates", and "Install" should be
merged into a common download link. They all are the same thing. ;]

I completely agree with you that not everything can live in the
header.

However Worg is a key component because it's community maintained
documentation. Not just anyone can upload to the main site, but Worg
is as "wiki" as we have. As an integral part of the community
supported documentation I thought it should be in the header.

I'm not suggesting any other header spam. ;]


--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: export to beamer: author and dynamic effects are not exported.

[Uwe Brauer]

>>> "ESF" == Eric S Fraga  writes:

> On Monday, 14 Dec 2020 at 14:08, Uwe Brauer wrote:
>> Documentation:
>> Non-nil means insert author name into the exported file.
>> This option can also be set with the OPTIONS keyword,
>> e.g. "author:nil".
>> 
>> But it is not clear how to set this 

> #+options: author:nil

Ok thanks
> The other thing that works is to simply have an empty author:

> #+author:

Sigh, this is so obvious that it did not occur to me. Thanks 


smime.p7s
Description: S/MIME cryptographic signature

Re: TEC: update the new website ML page?

[TEC]

Eric S Fraga  writes:

> Conclusion is that there is no conclusion.

Sounds about right .

Thanks for the link Eric.

--
Timothy

Re: TEC: update the new website ML page?

[Eric S Fraga]

On Monday, 14 Dec 2020 at 23:37, TEC wrote:
> 1. I'm very wary of "header creep", see

Interesting article, albeit a little old maybe, here:

https://www.humanfactors.com/newsletters/breadth_vs_depth_we_revisit_this_question.asp

Conclusion is that there is no conclusion.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-160-g7c8dce

Re: Emacs as an Org LSP server

[TEC]

Hi Neil,



Good to hear that you did take a look at the readme .



You can think of the LSP as a specification for cross-editor/IDE extensions. The
intent of this is to make some of Org’s functionality accessible to the ~95% of
people who don’t use Emacs, by hooking into Emacs itself.



Does that clear things up for you? You can also see https://langserver.org/.




All the best,Timothy




From: ">Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: ">TEC
Cc: "org-mode-email" 
Date: Mon, 14 Dec 2020 23:46:12 +0800
Thanks Timothy.  I did read the README, but I'm afraid I still can't quite picture a specific use.On Mon, 14 Dec 2020 at 15:28, TEC  wrote:

Hi Neil,



I’m going to quote you the readme from the linked github repo:



Allow the unwashed masses to use Org, without using Emacs, using Emacs.




Here’s the image from the readme



And here’s the first line from the first result of a google search for ”:



The Language Server Protocol (LSP) defines the protocol used between an editor
or IDE and a language server that provides language features like auto complete,
go to definition, find all references etc.




That should give you an idea of the intent here.




All the best,Timothy




From: Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: TEC
Cc: "org-mode-email" 
Date: Mon, 14 Dec 2020 19:41:05 +0800
Could you describe a use case?  Apologies if I missed this in earlier threads.On Sun, 13 Dec 2020 at 10:44, TEC  wrote:
A little progress update.https://github.com/tecosaur/org-lsp now exists.
I have no idea what I'm doing, so if anyone has feedback on the current
idea, that would be much appreciated.
TEC  writes:
> Hi Everyone,
>
> From the Org standardisation effort the idea of using Emacs as the basis
> of an LSP server for Org has been mentioned a few times.
>
> I thought this deserved it's own thread so here it is :)
>
> I'm quite keen to investigate the viability of this idea.
> Some key questions that I think need addressing are:
> 1. How can we 'package' Emacs into an LSP client?
> 2. Assuming we use some language as the basis for the host how do  we
>    want to pick it? LSP library? Lisp? Are there any outstanding
>    contenders.
> 3. How much effort is involved? Is it worth it to try to make Org  more
>    approachable* (without Emacs)?
>
> Lastly, but perhaps even more crucially --- who would be interested in
> working on this? I certainly am, but this feels like something that
> would be more viable with a small working group.
>
> Who's interested?
>
> Timothy.
>
>
> * I can't help but think that this hypothetical LSP server may   serve as
>  a 'gateway drug' to Org in Emacs 

Re: TEC: update the new website ML page?

[TEC]

Bastien  writes:

> FWIW, I just slightly updated this page with this paragraph:
>
> If you are not a subscriber to the list, you can still send an email
> to emacs-orgmode@gnu.org, we will add you to the whitelist of people
> who can reach the list.



>> As a second request, can we get a link to Worg on the top level bar?
>
> I'd rather let Timothy decide on this, as he has the whole picture.

Thanks Bastien :)

Hi Russel, while I appreciate the significance of Worg, I currently
don't feel that adding it to the header improves the site.

There are two concerns I have on this.

1. I'm very wary of "header creep", see https://0x0.st/iFS7.png for a
   mock up of an "extreme" example.
   IMO the current state is "bulging", with 4-6 items as the ideal.
   Adding Worg would take us to 8. In addition to the increased number
   of visual elements, it also lessens the individual significance of
   the per-existing items. If a "features" item has 3 other items, it is
   much more emphasised than when it has 7 other items.

   This is just a long winded way of me expressing the view that adding
   to the header affects the perception of the rest of the header, and
   thus the overall effect may be negative, as I suspect it would be in
   this case.

2. Worg is usually linked to in very specific instances, e.g.
   "(scientific) papers [about Org]", "The FAQ", "Using Org as a
   spreadsheet".
   It is also often linked, 11 times on the index page for instance.
   This makes me suspect that there is not sufficient benefit in adding
   it to the header.

I could well be missing something obvious, but those are my current
thoughts.

--
Timothy

Re: Emacs as an Org LSP server

[Neil Jerram]

Thanks Timothy.  I did read the README, but I'm afraid I still can't quite
picture a specific use.


On Mon, 14 Dec 2020 at 15:28, TEC  wrote:

> Hi Neil,
>
> I’m going to quote you the readme from the linked github repo:
>
> Allow the unwashed masses to use Org, without using Emacs, using Emacs.
>
> Here’s the image from the readme [image: model.png]
>
> And here’s the first line from the first result of a google search for
> ”:
>
> The Language Server Protocol (LSP) defines the protocol used between an
> editor or IDE and a language server that provides language features like
> auto complete, go to definition, find all references etc.
>
> That should give you an idea of the intent here.
>
> All the best,
> *Timothy*
>
> * From*: Neil Jerram <%22neil+jerram%22+%3cneiljer...@gmail.com%3E>
> * Subject*: Re: Emacs as an Org LSP server
> * To*: TEC <%22tec%22+%3ctecos...@gmail.com%3E>
> * Cc*: "org-mode-email" 
> * Date*: Mon, 14 Dec 2020 19:41:05 +0800
> Could you describe a use case?  Apologies if I missed this in earlier
> threads.
>
>
> On Sun, 13 Dec 2020 at 10:44, TEC  wrote:
>
>>
>> A little progress update.
>>
>> https://github.com/tecosaur/org-lsp now exists.
>>
>> I have no idea what I'm doing, so if anyone has feedback on the current
>> idea, that would be much appreciated.
>>
>> TEC  writes:
>>
>> > Hi Everyone,
>> >
>> > From the Org standardisation effort the idea of using Emacs as the basis
>> > of an LSP server for Org has been mentioned a few times.
>> >
>> > I thought this deserved it's own thread so here it is :)
>> >
>> > I'm quite keen to investigate the viability of this idea.
>> > Some key questions that I think need addressing are:
>> > 1. How can we 'package' Emacs into an LSP client?
>> > 2. Assuming we use some language as the basis for the host how do  we
>> >want to pick it? LSP library? Lisp? Are there any outstanding
>> >contenders.
>> > 3. How much effort is involved? Is it worth it to try to make Org  more
>> >approachable* (without Emacs)?
>> >
>> > Lastly, but perhaps even more crucially --- who would be interested in
>> > working on this? I certainly am, but this feels like something that
>> > would be more viable with a small working group.
>> >
>> > Who's interested?
>> >
>> > Timothy.
>> >
>> >
>> > * I can't help but think that this hypothetical LSP server may   serve
>> as
>> >  a 'gateway drug' to Org in Emacs 
>>
>>
>>

Re: Emacs as an Org LSP server

[TEC]

Hi Neil,



I’m going to quote you the readme from the linked github repo:



Allow the unwashed masses to use Org, without using Emacs, using Emacs.




Here’s the image from the readme



And here’s the first line from the first result of a google search for ”:



The Language Server Protocol (LSP) defines the protocol used between an editor
or IDE and a language server that provides language features like auto complete,
go to definition, find all references etc.




That should give you an idea of the intent here.




All the best,Timothy




From: ">Neil Jerram
Subject: Re: Emacs as an Org LSP server
To: ">TEC
Cc: "org-mode-email" 
Date: Mon, 14 Dec 2020 19:41:05 +0800
Could you describe a use case?  Apologies if I missed this in earlier threads.On Sun, 13 Dec 2020 at 10:44, TEC  wrote:
A little progress update.https://github.com/tecosaur/org-lsp now exists.
I have no idea what I'm doing, so if anyone has feedback on the current
idea, that would be much appreciated.
TEC  writes:
> Hi Everyone,
>
> From the Org standardisation effort the idea of using Emacs as the basis
> of an LSP server for Org has been mentioned a few times.
>
> I thought this deserved it's own thread so here it is :)
>
> I'm quite keen to investigate the viability of this idea.
> Some key questions that I think need addressing are:
> 1. How can we 'package' Emacs into an LSP client?
> 2. Assuming we use some language as the basis for the host how do  we
>    want to pick it? LSP library? Lisp? Are there any outstanding
>    contenders.
> 3. How much effort is involved? Is it worth it to try to make Org  more
>    approachable* (without Emacs)?
>
> Lastly, but perhaps even more crucially --- who would be interested in
> working on this? I certainly am, but this feels like something that
> would be more viable with a small working group.
>
> Who's interested?
>
> Timothy.
>
>
> * I can't help but think that this hypothetical LSP server may   serve as
>  a 'gateway drug' to Org in Emacs 

Re: Release Org 9.4.2

[Bastien]

Hi Pankaj,

Pankaj Jangid  writes:

> Bastien  writes:
>
>> I've released Org 9.4.2, a bugfix release.
>>
>> This version was merged with the emacs-27 branch:
>
> This is the only code that goes into stable branch first and then into
> ‘master’. Probably we need tweak the process a bit.

Sorry, I don't understand your concern here.  What should be done
differently?

-- 
 Bastien

Re: export to beamer: author and dynamic effects are not exported.

[Eric S Fraga]

On Monday, 14 Dec 2020 at 14:08, Uwe Brauer wrote:
> Documentation:
> Non-nil means insert author name into the exported file.
> This option can also be set with the OPTIONS keyword,
> e.g. "author:nil".
>
> But it is not clear how to set this 

#+options: author:nil

The other thing that works is to simply have an empty author:

#+author:


-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-160-g7c8dce

Re: Org Capture Menu cannot be fully viewed

[Marco Wahl]

pie...@caramail.com writes:

>> Would be great if you could check out the fix.
>
> Of coarse.  Is the following command the right way to get the fix
> for testing?
>
> git clone https://code.orgmode.org/bzg/org-mode.git

This is a step in the right direction. With this line you get a fresh
clone of the latest code.

If you just start using Org from the repo you could check the
instructions for the install over at orgmode.org ~~> Install. In the
long run this is the best way, I think.

In the case of this fix, for which only function org-mks has been
changed, I'd recommend to just evaluate that function.

This means the following. Have the newest function org-mks in an Emacs
buffer. This could be the function org-mks in file org-macs.el from your
fresh clone. Then place the cursor behind the very last paren of
function org-mks and do C-x C-e. And then check the thing.


Best regards,
--
Marco

Re: export to beamer: author and dynamic effects are not exported.

[Uwe Brauer]

>>> "ESF" == Eric S Fraga  writes:

> On Monday, 14 Dec 2020 at 10:19, Uwe Brauer wrote:
>> Consider please the following example 

> [...]

>> It should be exported as
>> 
>> \author{Uwe Brauer}

> It does for me.

Ok I had set 
org-export-with-author to nil
now I set it to t and the export works, 

*however* set to t it *always* exports, setting to nil it *never*
 exports.

I would like that it only exports if the field 
#+AUTHOR is present.

This seems to be impossible the documentation states

Documentation:
Non-nil means insert author name into the exported file.
This option can also be set with the OPTIONS keyword,
e.g. "author:nil".

But it is not clear how to set this 

I tried 
#+TITLE: This title
#+AUTHOR:
:PROPERTIES:
:AUTHOR:nil
:END:

But this did not work as expected.

>> and the dynamic effect as 

> Use BEAMER_act instead of BEAMER_opt and specify the property as [<+->],
> i.e. with square brackets.

Thanks, this was helpful


smime.p7s
Description: S/MIME cryptographic signature

Re: Org Capture Menu cannot be fully viewed

[pietru]

> Sent: Monday, December 14, 2020 at 1:41 PM
> From: "Marco Wahl" 
> To: pie...@caramail.com
> Cc: "Org-Mode mailing list" 
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> Hi Pietru and all,
>
> > When making a relatively long Org Capture Menu for Archaeological Field 
> > Management,
> > the relevant capture window cannot be scrolled down.  This becomes 
> > particularly
> > problematic with small field laptops.
>
> Thanks for reporting.
>
> I just committed a fix along the lines of the similar exporter-UI and
> the agenda chooser-UI. Now there is at least C-n, C-p, C-v when the
> window is too small for all the items.
>
> Unfortunately these similar UIs are not unified when looking at the code
> base. E.g. I could not find a simple way to add key M-v to scroll one
> page up for the capture menu.
>
> Possibly these UIs could be unified or Org could even switch to
> something different. I think you already discussed some ideas. Sorry if
> I did not read the whole thread. That was too much information for me.

Don't worry about it.  I thank you for taking an interest towards a fix.

> Would be great if you could check out the fix.

Of coarse.  Is the following command the right way to get the fix
for testing?

git clone https://code.orgmode.org/bzg/org-mode.git


> Thanks and HTH,
> --
> Marco
>

Re: Bring up a screen giving option to open a series of orgmode files

[Ihor Radchenko]

Jean Louis  writes:

> * Ihor Radchenko  [2020-12-13 03:39]:
>> Jean Louis  writes:
>> I have hypothes.is installed inside docker container locally. No serious
>> protection is required in such case (at least, no more than one would
>> use to protect private files from dangerous software like browsers).
>
> I can install it on VPS which is definitely in plan. Locally I do not
> think so, as locally I have dynamic knowledge repository that may
> export to Org if necessary or accessed by collaborative group of
> people. 

I am actually just trying hyposes.is now (after you reminded me about
it). For me, the main advantage is not for pdfs, but rather the ability
to have pdf-like annotations in web-pages: highlights, comments, etc.
Combined with local ArchiveBox [1] storage, I can get annotations for my
local web archive.

[1] https://github.com/ArchiveBox/ArchiveBox

>> I am not sure how it is different from using hypothes.is for the same
>> purpose. Note that hypothes.is uses pdf fingerprinting, so you don't
>> even need to store pdf on server side. If user can open the pdf
>> (obtained from you directly, for example), hypothes.is will
>> automatically show the up-to-date annotations shared via public
>> hypothes.is instance for that particular user.
>
> The difference is that annotation is separate from file, and there is
> no need for Javascript. Hyperdocument may contain the PDF file and the
> annotation together, dispatched to somebody, or referenced from WWW
> page. It is lightweight. HTML file can be very small and speedy
> loaded. 

Hypothes.is does not store the file - just file fingerprint and
information required to identify and annotation positions within the
file.

Best,
Ihor

Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options

[Ihor Radchenko]

Jean Louis  writes:
> Do you mean this:
>
> ** DONE Objective
>CLOSED: [2020-12-13 Sun 20:00]
> *** TODO [#B] Step to do 1
> *** TODO Step to do 2
>
> when org-enforce-todo-dependencies is true I can still say DONE for
> Objective above. I have mentioned it today already. Maybe it works on
> your side, it does not work here. Do I do something wrong? I am on
> development Emacs version and it does not enforce under emacs -Q

>> I cannot reproduce what you observe. Also, one can forcefully change
>> todo state to done even when org-enforce-todo-dependencies is set to
>> TRUE. To do it, C-u C-u C-u C-c C-t needs to be used instead of C-c C-t
>> for setting the todo state.
>
> I can observe in emacs -Q from development version.
>
> So you say when you try to close senior heading that you cannot close
> it? I can when that variable is true or nil, do you think it is bug?
>
> I can give you access to Emacs over remote ssh and you can try because
> if it is bug, it is serious for those other thinkers but me.

I just looked into this more. Most likely you were trying to set this
variable manually. To take effect, this variable should be set using
customisation interface, before loading org, or you may need to run M-x
org-reload.

> It looks like I am only one observing that. And especially me I do not
> like depending on Org mode to dictate how to close items. So when
> there is somebody else to join in the notion that is where feature is
> appropriate. Otherwise I consider Org rather made and designed for
> other way thinkers and doers, not for us who think from senior
> objectives as priorities where subordinate items should become
> redundant and not marked as "done".

org-mode is developed mostly be enthusiasts. Some popular features are
used by many different people using different workflows. Those features
get a lot of attention and become quite customisable. Other features,
are only used by their author and maybe a few other people who agree on
the way the feature is implemented. Naturally, these less commonly used
features are more biased towards their author's workflows. However, I
don't see why a patch improving org-mode flexibility would not be
welcome. 

> My personal list of for a day has 7 items currently. Not 250. Those
> are rather objectives, goals and purposes. Single items under
> objectives are well known actions to be done and need not be marked as
> TODO, but I can. My focus is on the meaning of what has to be done and
> I do not need to look into tags or properties. Your informational
> emails gave me to thinking so I have implemented it all.

I also find it helpful to combine the objective + a note about concrete
action to take on the objective. The concrete action helps to get
started on the objective without drowning myself into thinking (but not
doing) about all the things I need to do on that objective.

>> Note that you are also risking to complain about things that are
>> actually not a problem. Simply because you don't have a need to
>> investigate what is possible.
>
> Yes, some of those needs disappeared when I have seen so many
> obstacles. I did not use some features like org-agenda because it was
> in front of me what I have to do. Things were not scattered like Org
> manual advises and I disadvise. It is different paradigm approach and
> so for many needs I need not even investigate what is possible. I am
> interested in paradigms, approaches, methods but not in general in
> gluing things together which are not meant to be together.

Would you mind writing a paragraph or two to improve the "5 TODO Items"
section of the manual? At least, we can inform people that the ability
to scatter todo items all around the documents does not mean that it has
to be done.

> Jean

Re: Org Capture Menu cannot be fully viewed

[Marco Wahl]

Hi Pietru and all,

> When making a relatively long Org Capture Menu for Archaeological Field 
> Management,
> the relevant capture window cannot be scrolled down.  This becomes 
> particularly
> problematic with small field laptops.

Thanks for reporting.

I just committed a fix along the lines of the similar exporter-UI and
the agenda chooser-UI. Now there is at least C-n, C-p, C-v when the
window is too small for all the items.

Unfortunately these similar UIs are not unified when looking at the code
base. E.g. I could not find a simple way to add key M-v to scroll one
page up for the capture menu.

Possibly these UIs could be unified or Org could even switch to
something different. I think you already discussed some ideas. Sorry if
I did not read the whole thread. That was too much information for me.

Would be great if you could check out the fix.


Thanks and HTH,
--
Marco

org-todo-yesterday with 1-day repeater tasks: repeats tomorrow

[Ken Mankoff]

Hello list,

I regularly use org-todo-yesterday or org-agenda-todo-yesterday. However, with 
a 1-day repeater task, or any ++ repeater, it sets the repetition using today 
as the starting point, not yesterday.

It seems like the repeater time and date-setter is not respecting 
"org-extend-today-until", which has this wonderful docstring:

"""IMPORTANT:  This is a feature whose implementation is and likely will
remain incomplete.  Really, it is only here because past midnight seems to
be the favorite working time of John Wiegley :-)"""

Are other experiencing this behavior? Is there some prefix arg I am missing 
that I should be using? I have not found other complaining about this behavior 
or reporting this issue, so I wonder if I'm missing something. If not, I'll 
work on submitting a patch.

Thanks,

  -k.

Re: Emacs as an Org LSP server

[Neil Jerram]

Could you describe a use case?  Apologies if I missed this in earlier
threads.


On Sun, 13 Dec 2020 at 10:44, TEC  wrote:

>
> A little progress update.
>
> https://github.com/tecosaur/org-lsp now exists.
>
> I have no idea what I'm doing, so if anyone has feedback on the current
> idea, that would be much appreciated.
>
> TEC  writes:
>
> > Hi Everyone,
> >
> > From the Org standardisation effort the idea of using Emacs as the basis
> > of an LSP server for Org has been mentioned a few times.
> >
> > I thought this deserved it's own thread so here it is :)
> >
> > I'm quite keen to investigate the viability of this idea.
> > Some key questions that I think need addressing are:
> > 1. How can we 'package' Emacs into an LSP client?
> > 2. Assuming we use some language as the basis for the host how do  we
> >want to pick it? LSP library? Lisp? Are there any outstanding
> >contenders.
> > 3. How much effort is involved? Is it worth it to try to make Org  more
> >approachable* (without Emacs)?
> >
> > Lastly, but perhaps even more crucially --- who would be interested in
> > working on this? I certainly am, but this feels like something that
> > would be more viable with a small working group.
> >
> > Who's interested?
> >
> > Timothy.
> >
> >
> > * I can't help but think that this hypothetical LSP server may   serve as
> >  a 'gateway drug' to Org in Emacs 
>
>
>

Re: stability of toc links

[Dominique Dumont]

On Wednesday, 9 December 2020 00:28:46 CET Samuel Wales wrote:
> when you link to a section using toc, you get a link like
>  
> https://thekafkapandemic.blogspot.com/2020/02/crimes-against-humanity_3.htm
> l#org080f0ab
> 
> will these links break if somebody copies them and pastes them
> elsewhere?  what if you add a section?

I have a similar problem. I write documentation for a customer in org format. 
I also have to generate Markdown files that are archived in a git repo (Unlike 
Github, Azure DevOps doesn't support org files).

Currently, TOC and headers lines change every time the markdown files are 
regenerated, which makes git diff much bigger, which also impacts code reviews.

So stabilizing the generated toc would be much welcome

All the best

Re: export to beamer: author and dynamic effects are not exported.

[Eric S Fraga]

On Monday, 14 Dec 2020 at 10:19, Uwe Brauer wrote:
> Consider please the following example 

[...]

> It should be exported as
>
> \author{Uwe Brauer}

It does for me.

> and the dynamic effect as 

Use BEAMER_act instead of BEAMER_opt and specify the property as [<+->],
i.e. with square brackets.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-160-g7c8dce

Re: [PATCH] Enhance org-html--build-meta-info

[Jens Lechtenboerger]

Hi everybody,

On 2020-12-14, Bastien wrote:

> Hi Timothy,
>
> TEC  writes:
>
>> Thanks for testing this :) I haven't forgotten about this.
>
> Let's wait for Jens feedback on this patch, since he took care of
> testing it so far.

I exported this:

#+begin_src org
,#+TITLE: A title with *bold* index_1^2 and characters &ß<"
,#+AUTHOR: An /emphasized/ "anonymous" author_1^2 with 
[[https://example.org][hyperlink]] and characters &ß<"
,#+DESCRIPTION: A description_1^2 with /emphasis/ and 
[[https://example.org][hyperlink]] and characters &ß<"
,#+KEYWORDS: key, wörd, *bold*, sub_script

Test
#+end_src

The title now exports follows, which needs fixing:
A title with 

What about treating the title like the author?  (Again, Org mode
currently produces invalid HTML as nested sub-elements are produced
inside the title element.)

The keywords export as follows, where the name attribute is missing:


The current lambda functions in org-html-meta-tags all accept three
arguments, where the first one is ignored in all cases.  The second
one is used in exactly one case.  Why not add four calls to
org-html--build-meta-entry (for author, description, keywords,
generator) in org-html--build-meta-info?

Best wishes
Jens

export to beamer: author and dynamic effects are not exported.

[Uwe Brauer]

Hi 

Consider please the following example 

#+TITLE: This title
#+AUTHOR: Uwe Brauer

* This is an example
:PROPERTIES:
:BEAMER_opt: <+->
:END:

Now

1. This

2. That 

It should be exported as

\author{Uwe Brauer}
and the dynamic effect as 

\begin{frame}[<+->][label={sec:orge797871}]{This is an example}

But it is not, instead 

\begin{frame}[label={sec:orgb41a8d4},<+->]{This is an example}

Which does not compile correctly

Moreover the author is ignored (there is pdfauthor however which
does not get compiled) and 



I attach the org file the resulting tex file and the corrected tex file

Regards

Uwe Brauer 


% Created 2020-12-14 lun 10:15
% Intended LaTeX compiler: pdflatex
\documentclass[presentation]{beamer}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage[numbered,framed]{matlab-prettifier}
\usetheme{default}
\date{\today}
\title{This title}
\hypersetup{
 pdfauthor={Uwe Brauer},
 pdftitle={This title},
 pdfkeywords={},
 pdfsubject={},
 pdfcreator={Emacs 28.0.50 (Org mode 9.3.7)}, 
 pdflang={English}}
\begin{document}

\maketitle

\begin{frame}[label={sec:orgb41a8d4},<+->]{This is an example}
Now

\begin{enumerate}
\item This

\item That
\end{enumerate}
\end{frame}
\end{document}#+TITLE: This title
#+AUTHOR: Uwe Brauer

* This is an example
:PROPERTIES:
:BEAMER_opt: <+->
:END:

Now

1. This

2. That 
% Created 2020-12-14 lun 10:13
% Intended LaTeX compiler: pdflatex
\documentclass[presentation]{beamer}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage[numbered,framed]{matlab-prettifier}
\usetheme{default}
\date{\today}
\title{This title}
\author{Uwe Brauer }
\hypersetup{
 pdfauthor={Uwe Brauer},
 pdftitle={This title},
 pdfkeywords={},
 pdfsubject={},
 pdfcreator={Emacs 28.0.50 (Org mode 9.3.7)}, 
 pdflang={English}}
\begin{document}

\maketitle

\begin{frame}[<+->][label={sec:orge797871}]{This is an example}
Now

\begin{enumerate}
\item This

\item That
\end{enumerate}
\end{frame}
\end{document}

Re: ox-slimhtml

[tomas]

On Mon, Dec 14, 2020 at 12:48:27AM -0500, Laszlo Elo wrote:
> Hello,
> 
> Amin was kind enough to poke me to submit and post about my package, 
> ox-slimhtml.
> In a nutshell, it is an org-export backend - transcodes Org elements to 
> HTML/text output.

Thank you (both :)

Cheers
 - t


signature.asc
Description: Digital signature

Re: [PATCH] babel latex headers and image generation commands

[Bastien]

Matt Huszagh  writes:

>> Can you provide a patch against etc/ORG-NEWS announce this?
>
> Attached. Let me know what you think.

Applied (2af68d6a4) with a minor modification in the headline.

Thanks,

-- 
 Bastien