Re: Getting X selection reliably (Re: idea for capture anywhere in x)

[Max Nikulin]

On 14/11/2022 09:06, Ihor Radchenko wrote:

Max Nikulin writes:


Depending of particular capture template (even with :immediate-finish t)
empty selection may or may not be an error. In Samuel's case it is an
error. Unfortunately, while the template is processed, signaled errors
are caught and their text is inserted into the text. That is why in my
example I put checks outside of `org-capture'.


Are you sure? `org-get-x-clipboard' returns nil in case of error and
`org-capture-fill-template' assigns empty string to v-x when no
clipboard value can be obtained.


I did not mean elisp error. It is a trouble from the point of view of a 
user. Their expect to get selection text, but actually useless empty 
string is inserted. However capturing stale selection (from previous 
action) is an equally annoying trouble. That is why I believe, the only 
reliable way is to present result of capture to the user, so if 
something goes wrong then they may redo selection and capture. Samuel 
may weight distracting popup vs. a chance of useless capture differently.



We may:
- Add a capture template option that allows errors to pass through to
the caller. Then a user may add %(...) expression with all necessary checks.


I am not very sure what kind of errors you are talking about. AFAIU, we
are talking about scenarios when user explicitly wants one of
PRIMARY/CLIPBOARD/SECONDARY, don't we?


I mean a way to propagate an error signaled during capture expansion to 
the caller of emacsclient, so user may be notified about the issue 
instead of silently getting "[ERROR ...]" in the captured heading.



I have no idea how to get "emacs -display" argument and I need to look
into emacsclient source and server.el to figure out which way client's
display argument is passed to the server process.


Maybe it can be considered an Emacs bug or something to improve on Emacs
side?


See Max Nikulin to emacs-devel. How to get DISPLAY of emacsclient? Fri, 
25 Nov 2022 22:17:54 +0700. mid:tlqmb3$ic$1...@ciao.gmane.io


A workaround is

  emacsclient --display "$DISPLAY" --eval ...

Unlike for most of X applications, --display option of emacsclient not 
only overrides the value of the DISPLAY environment, in addition it 
causes creation of a hidden frame, so `org-get-x-clipboard' is able to 
get selection text. I am unsure concerning behavior in other OSes. At 
least special values display are used internally, users are unlikely 
familiar with the concept of display. Unfortunately I can not check 
precise behavior for macOS or Windows. I would not mind to have an 
option like --force-display that does not require fetching the value 
from environment (to avoid explicit shell wrapper in .desktop files) or 
special values on non-X systems.


Likely the "--display" hack should be mentioned in the manual and in the 
templates docscring.

Re: Getting X selection reliably (Re: idea for capture anywhere in x)

[Jean Louis]

* Samuel Wales  [2022-11-16 07:06]:
> idk if related to this thread, but i sure do appreciate the effor in
> this thread to solve such problems.  it is a key feature for me
> because i am often in mouse-only mode.  it is thus a constant concern
> that org-capture could stop working etc.
> 
> right now, it seems org-capture is broken for me again.  clicking on
> unicorn results in the momentary captured indication in huge text on
> the screen [i like this indicator], but it does not get captured to my
> org capture target.

I am using reliable org-protocol extension, that can "store" link and
"capture", it is programmed by Wojciech Siewierski,
https://github.com/vifon/org-protocol-for-firefox 

https://addons.mozilla.org/en-US/firefox/addon/org-protocol/reviews/


-- 
Jean

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

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

Re: Getting X selection reliably (Re: idea for capture anywhere in x)

[Samuel Wales]

idk if related to this thread, but i sure do appreciate the effor in
this thread to solve such problems.  it is a key feature for me
because i am often in mouse-only mode.  it is thus a constant concern
that org-capture could stop working etc.

right now, it seems org-capture is broken for me again.  clicking on
unicorn results in the momentary captured indication in huge text on
the screen [i like this indicator], but it does not get captured to my
org capture target.

this is with or without selecting any text.

could a kind soul remind me how to debug this again?

i have made no changes to my capture template or code in a very long
time.  i don't think firefox-esr has updated recently.


On 11/13/22, Ihor Radchenko  wrote:
> Max Nikulin  writes:
>
>>> I am unsure what can be done here. AFAIU, Org just follows the %x
>>> description. Nothing wrong on Org side.
>>>
>>> The best we can do is alternative %?? that will do something more
>>> reliable. But I am unsure what it can be.
>>
>> Depending of particular capture template (even with :immediate-finish t)
>> empty selection may or may not be an error. In Samuel's case it is an
>> error. Unfortunately, while the template is processed, signaled errors
>> are caught and their text is inserted into the text. That is why in my
>> example I put checks outside of `org-capture'.
>
> Are you sure? `org-get-x-clipboard' returns nil in case of error and
> `org-capture-fill-template' assigns empty string to v-x when no
> clipboard value can be obtained.
>
>> We may:
>> - Add a capture template option that allows errors to pass through to
>> the caller. Then a user may add %(...) expression with all necessary
>> checks.
>
> I am not very sure what kind of errors you are talking about. AFAIU, we
> are talking about scenarios when user explicitly wants one of
> PRIMARY/CLIPBOARD/SECONDARY, don't we?
>
 2. Jean pointed out that Emacs ignores X selection if it does not have
 an X frame. It was almost buried in the haystack of "SQL instead of
 Org"
 noise. It happens if Emacs is running as a daemon. I am unsure which
 way
 Samuel starts Emacs (xinit, systemd user session, systemd socket
 activation, manually, etc.)
>>>
>>> May we modify org-get-x-clipboard adding
>>> (server-select-display (getenv \"DISPLAY\")) ?
>>> Will it be enough?
>>
>> It will work for most of users, however sometimes it is incorrect. There
>> are a number of options that should have higher priority than emacs
>> server DISPLAY environment
>> - emacsclient -display command line option,
>> - emacsclient process DISPLAY environment,
>> - emacs -display server argument.
>>
>> I have no idea how to get "emacs -display" argument and I need to look
>> into emacsclient source and server.el to figure out which way client's
>> display argument is passed to the server process.
>
> Maybe it can be considered an Emacs bug or something to improve on Emacs
> side?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
>


-- 
The Kafka Pandemic

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

Re: Getting X selection reliably (Re: idea for capture anywhere in x)

[Ihor Radchenko]

Max Nikulin  writes:

>> I am unsure what can be done here. AFAIU, Org just follows the %x
>> description. Nothing wrong on Org side.
>> 
>> The best we can do is alternative %?? that will do something more
>> reliable. But I am unsure what it can be.
>
> Depending of particular capture template (even with :immediate-finish t) 
> empty selection may or may not be an error. In Samuel's case it is an 
> error. Unfortunately, while the template is processed, signaled errors 
> are caught and their text is inserted into the text. That is why in my 
> example I put checks outside of `org-capture'.

Are you sure? `org-get-x-clipboard' returns nil in case of error and
`org-capture-fill-template' assigns empty string to v-x when no
clipboard value can be obtained.

> We may:
> - Add a capture template option that allows errors to pass through to 
> the caller. Then a user may add %(...) expression with all necessary checks.

I am not very sure what kind of errors you are talking about. AFAIU, we
are talking about scenarios when user explicitly wants one of
PRIMARY/CLIPBOARD/SECONDARY, don't we?

>>> 2. Jean pointed out that Emacs ignores X selection if it does not have
>>> an X frame. It was almost buried in the haystack of "SQL instead of Org"
>>> noise. It happens if Emacs is running as a daemon. I am unsure which way
>>> Samuel starts Emacs (xinit, systemd user session, systemd socket
>>> activation, manually, etc.)
>> 
>> May we modify org-get-x-clipboard adding
>> (server-select-display (getenv \"DISPLAY\")) ?
>> Will it be enough?
>
> It will work for most of users, however sometimes it is incorrect. There 
> are a number of options that should have higher priority than emacs 
> server DISPLAY environment
> - emacsclient -display command line option,
> - emacsclient process DISPLAY environment,
> - emacs -display server argument.
>
> I have no idea how to get "emacs -display" argument and I need to look 
> into emacsclient source and server.el to figure out which way client's 
> display argument is passed to the server process.

Maybe it can be considered an Emacs bug or something to improve on Emacs
side?

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

Re: Getting X selection reliably (Re: idea for capture anywhere in x)

[Max Nikulin]

On 13/11/2022 11:54, Ihor Radchenko wrote:

Max Nikulin writes:

On 26/10/2022 11:58, Ihor Radchenko wrote:


Yes. From org-capture-templates docstring:

%x  Content of the X clipboard.


Ihor, I am afraid there are a couple of pitfalls with "%x" for Samuel
since he prefers to keep Emacs hidden so can not check result.

1. If something goes wrong, e.g. some application does not put
highlighted text to PRIMARY selection then wrong source (CLIPBOARD) or
empty string may be silently captured. I would prefer explicit source
however it will not protect against stale selection from the same source.

Simulate empty selection:
echo | xsel -bi ; echo | xsel -i ; killall xsel


I am unsure what can be done here. AFAIU, Org just follows the %x
description. Nothing wrong on Org side.

The best we can do is alternative %?? that will do something more
reliable. But I am unsure what it can be.


Depending of particular capture template (even with :immediate-finish t) 
empty selection may or may not be an error. In Samuel's case it is an 
error. Unfortunately, while the template is processed, signaled errors 
are caught and their text is inserted into the text. That is why in my 
example I put checks outside of `org-capture'.


We may:
- Add a capture template option that allows errors to pass through to 
the caller. Then a user may add %(...) expression with all necessary checks.
- Add a warning note to "%x" or :immediate-finish docs to make users 
aware of possible pitfall.



2. Jean pointed out that Emacs ignores X selection if it does not have
an X frame. It was almost buried in the haystack of "SQL instead of Org"
noise. It happens if Emacs is running as a daemon. I am unsure which way
Samuel starts Emacs (xinit, systemd user session, systemd socket
activation, manually, etc.)


May we modify org-get-x-clipboard adding
(server-select-display (getenv \"DISPLAY\")) ?
Will it be enough?


It will work for most of users, however sometimes it is incorrect. There 
are a number of options that should have higher priority than emacs 
server DISPLAY environment

- emacsclient -display command line option,
- emacsclient process DISPLAY environment,
- emacs -display server argument.

I have no idea how to get "emacs -display" argument and I need to look 
into emacsclient source and server.el to figure out which way client's 
display argument is passed to the server process.

Re: Getting X selection reliably (Re: idea for capture anywhere in x)

[Ihor Radchenko]

Max Nikulin  writes:

> On 26/10/2022 11:58, Ihor Radchenko wrote:
>> 
>> Yes. From org-capture-templates docstring:
>> 
>>%x  Content of the X clipboard.
>
> Ihor, I am afraid there are a couple of pitfalls with "%x" for Samuel 
> since he prefers to keep Emacs hidden so can not check result.
>
> 1. If something goes wrong, e.g. some application does not put 
> highlighted text to PRIMARY selection then wrong source (CLIPBOARD) or 
> empty string may be silently captured. I would prefer explicit source 
> however it will not protect against stale selection from the same source.
>
> Simulate empty selection:
> echo | xsel -bi ; echo | xsel -i ; killall xsel

I am unsure what can be done here. AFAIU, Org just follows the %x
description. Nothing wrong on Org side.

The best we can do is alternative %?? that will do something more
reliable. But I am unsure what it can be.

> 2. Jean pointed out that Emacs ignores X selection if it does not have 
> an X frame. It was almost buried in the haystack of "SQL instead of Org" 
> noise. It happens if Emacs is running as a daemon. I am unsure which way 
> Samuel starts Emacs (xinit, systemd user session, systemd socket 
> activation, manually, etc.)

May we modify org-get-x-clipboard adding
(server-select-display (getenv \"DISPLAY\")) ?
Will it be enough?

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

Re: Getting X selection reliably (Re: idea for capture anywhere in x)

[Samuel Wales]

i am still slightly lost [varying cognitive issues] but wanted to make
one correction.  i think i have my capture set up so that my typical
capture location shows, although it is underneath ff so cannot be seen
at the time.  so a new frame in many cases is not necessary; the
existing emacs frame could pop up for a brief period in principle.
not much of a correction but there it is.

On 10/28/22, Samuel Wales  wrote:
> if what we are talking about is checking the text or metadata as org
> capture or emacs understands it against what we are capturing in a
> maximized application, by means of a popup and a human [myself], then:
>
> i'd say an emacs frame popping up over the application [whether the
> application is emacs or firefox or whatever] as just another frame for
> my normal emacs [which has some degree of optimization for ergo and
> accessibiity], but frame shrunk to fit the text, would actually be
> preferable to a separate popup application/notifier tool [which would
> require unfamiliar configuration and might not even be ergo or
> accessible or portable/lts], provided that it goes away after a
> configured delay, and does not require the keyboard or the mouse to
> make it go away.  so an emacs frame is not a bad idea, just has to be
> done right.  i think.
>
>> For other applications, since you have a requirement of maximized
>> application window and purely mouse action, I am
> unsure if you managed to configure fluxbox to add a custom menu entry
> accessible in such layout.
>
> fluxbox is the only wm or de that seems to do everything i need.  in
> this case, it is quite straightforward for me [or else i have put out
> of my mind any annoyance at previous years' efforts in making it
> work].
>
> what it does is have a bar that drops down when mouse pointer hits top
> edge of window.  this only works if the application is maximized or
> normalized rather than fullscreen in fluxbox's terminology.  and that
> is the case for everything i'd need to capture.  the only fullscreen
> apps i have are video players, and idk what the point of fullscreen is
> but with video players they seem to get fit to screen right then as
> opposed to having the video extend off teh edge of the screen or be
> tiny or whatever.  i do not need to capture from vlc or mpv.
> [although a super-fancy doug englebart demo type of pov might have me
> grabbing a few minutes of video and capturing it and then speech to
> text from the video and metadata would be captured but i am not
> holding my breath or expecting that.]
>
> then rclick on that fluxbox bar drops down a fluxbox menu of highly
> useful things, which i can add a line to in .fluxbox/.menu to add one.
> usually shell commands.  and also various fluxbox items like maximize
> and close.  and menus i never use courtesy of fluxbox and debian].  it
> is copacetic.  except for one rather annoying bug, which is that the
> bar stays there if i select anything from that manu, so i have to move
> pointer to the top again and then back to make it go away again.  i
> gave up trying to fix that bug, wish it could be fixed.  but adding a
> menu item is for me trivial.  so that part is not part of the problem.
> i just open .menu and cargo cult a line that says capture.
>
>
> On 10/28/22, Max Nikulin  wrote:
>> On 29/10/2022 09:59, Ihor Radchenko wrote:
>>> Max Nikulin writes:
>>>
 %(org-get-x-clipboard 'PRIMARY)
 "
   :immediate-finish t)

 However to be at the safe side I would check if (org-get-x-clipboard
 'PRIMARY) value is not nil at first.
>>>
>>> My approach to this is simply showing a popup with captured heading
>>> after capture. If anything is wrong, I can quickly notice.
>>>
>>> Not sure if it is suitable for Samuel though.
>>
>> I started with a small wrapper that checks if Emacs server is running
>> and creates a new frame if it does not exist yet. So I avoided a pitfall
>> with empty string instead of selection. I intentionally do not use
>> :immediate-finish to inspect capture and to add some comment.
>>
>> Samuel wish to have minimal distraction: no sound, no popup window,
>> Emacs window is not raised in front of current application, visual
>> notification should disappear after some pause.
>>
>> That is why I believe that additional checks are required in such silent
>> workflow to avoid missed data in notes.
>>
>>
>>
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

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

Re: Getting X selection reliably (Re: idea for capture anywhere in x)

[Max Nikulin]

On 29/10/2022 13:03, Samuel Wales wrote:


fluxbox is the only wm or de that seems to do everything i need.
Then you should have no problem to call `org-capture' using emacsclient 
as a menu entry action. Does it work for you? From my point of view 
"capture anywhere in x" task should be roughly solved. The following 
steps may be necessary to polish the approach and to make it reliable.


P.S. I forgot to post a link to a fluxbox bug that was quite annoying 
for me when I was trying to test something in a lightweight environment. 
I had to rebuild fluxbox package with an additional patch:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743772
Cannot move Gnome 3.12 applications

Re: Getting X selection reliably (Re: idea for capture anywhere in x)

[Samuel Wales]

if what we are talking about is checking the text or metadata as org
capture or emacs understands it against what we are capturing in a
maximized application, by means of a popup and a human [myself], then:

i'd say an emacs frame popping up over the application [whether the
application is emacs or firefox or whatever] as just another frame for
my normal emacs [which has some degree of optimization for ergo and
accessibiity], but frame shrunk to fit the text, would actually be
preferable to a separate popup application/notifier tool [which would
require unfamiliar configuration and might not even be ergo or
accessible or portable/lts], provided that it goes away after a
configured delay, and does not require the keyboard or the mouse to
make it go away.  so an emacs frame is not a bad idea, just has to be
done right.  i think.

> For other applications, since you have a requirement of maximized application 
> window and purely mouse action, I am
unsure if you managed to configure fluxbox to add a custom menu entry
accessible in such layout.

fluxbox is the only wm or de that seems to do everything i need.  in
this case, it is quite straightforward for me [or else i have put out
of my mind any annoyance at previous years' efforts in making it
work].

what it does is have a bar that drops down when mouse pointer hits top
edge of window.  this only works if the application is maximized or
normalized rather than fullscreen in fluxbox's terminology.  and that
is the case for everything i'd need to capture.  the only fullscreen
apps i have are video players, and idk what the point of fullscreen is
but with video players they seem to get fit to screen right then as
opposed to having the video extend off teh edge of the screen or be
tiny or whatever.  i do not need to capture from vlc or mpv.
[although a super-fancy doug englebart demo type of pov might have me
grabbing a few minutes of video and capturing it and then speech to
text from the video and metadata would be captured but i am not
holding my breath or expecting that.]

then rclick on that fluxbox bar drops down a fluxbox menu of highly
useful things, which i can add a line to in .fluxbox/.menu to add one.
usually shell commands.  and also various fluxbox items like maximize
and close.  and menus i never use courtesy of fluxbox and debian].  it
is copacetic.  except for one rather annoying bug, which is that the
bar stays there if i select anything from that manu, so i have to move
pointer to the top again and then back to make it go away again.  i
gave up trying to fix that bug, wish it could be fixed.  but adding a
menu item is for me trivial.  so that part is not part of the problem.
i just open .menu and cargo cult a line that says capture.


On 10/28/22, Max Nikulin  wrote:
> On 29/10/2022 09:59, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>
>>> %(org-get-x-clipboard 'PRIMARY)
>>> "
>>>   :immediate-finish t)
>>>
>>> However to be at the safe side I would check if (org-get-x-clipboard
>>> 'PRIMARY) value is not nil at first.
>>
>> My approach to this is simply showing a popup with captured heading
>> after capture. If anything is wrong, I can quickly notice.
>>
>> Not sure if it is suitable for Samuel though.
>
> I started with a small wrapper that checks if Emacs server is running
> and creates a new frame if it does not exist yet. So I avoided a pitfall
> with empty string instead of selection. I intentionally do not use
> :immediate-finish to inspect capture and to add some comment.
>
> Samuel wish to have minimal distraction: no sound, no popup window,
> Emacs window is not raised in front of current application, visual
> notification should disappear after some pause.
>
> That is why I believe that additional checks are required in such silent
> workflow to avoid missed data in notes.
>
>
>
>


-- 
The Kafka Pandemic

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

Re: Getting X selection reliably (Re: idea for capture anywhere in x)

[Max Nikulin]

On 29/10/2022 06:07, Samuel Wales wrote:

i am still lost in this and it will take me a while.

..

it is not a top priority for me at this time as long as the ff
org-capture extension works


Samuel, feel free came back with this question when you will have enough 
spare time and motivation to continue. Currently I am unsure with which 
pieces of the puzzle you still have difficulties.


I would separate the following cases:
- Emacs
- Application having dedicated plugins (Firefox works if I got it right)
- Other applications

As to Emacs, perhaps emacs-help mailing list is the appropriate place to 
ask how to add global mouse action. E.g. is it possible to add a button 
to modeline? If I am not mistaken, Emacs-28 has an option to enable 
right click menu similar to other applications.


For other applications, since you have a requirement of maximized 
application window and purely mouse action, I am unsure if you managed 
to configure fluxbox to add a custom menu entry accessible in such 
layout. By default only window and toolbar menu are available.


A tiny custom application displaying a tray icon might be a way to 
initiate capture through mouse click. Unsure if Emacs can add such icon.

Re: Getting X selection reliably (Re: idea for capture anywhere in x)

[Max Nikulin]

On 29/10/2022 09:59, Ihor Radchenko wrote:

Max Nikulin writes:


%(org-get-x-clipboard 'PRIMARY)
"
  :immediate-finish t)

However to be at the safe side I would check if (org-get-x-clipboard
'PRIMARY) value is not nil at first.


My approach to this is simply showing a popup with captured heading
after capture. If anything is wrong, I can quickly notice.

Not sure if it is suitable for Samuel though.


I started with a small wrapper that checks if Emacs server is running 
and creates a new frame if it does not exist yet. So I avoided a pitfall 
with empty string instead of selection. I intentionally do not use 
:immediate-finish to inspect capture and to add some comment.


Samuel wish to have minimal distraction: no sound, no popup window, 
Emacs window is not raised in front of current application, visual 
notification should disappear after some pause.


That is why I believe that additional checks are required in such silent 
workflow to avoid missed data in notes.

Re: Getting X selection reliably (Re: idea for capture anywhere in x)

[Ihor Radchenko]

Samuel Wales  writes:

> not sure i am following everything but it seems a popup that goes away
> after a very short period of time shows adequately that first contact
> was made with emacs.  then, including the captured text shows that
> there isn't another issue?

Let me elaborate.

What I have in mind is org-capture-before-finalize-hook.
Functions in this hook is executed at the end of the capture process
before the capture buffer is killed. You may reasonably assume that the
capture is successful if the hook is run.

Functions in org-capture-before-finalize-hook have access to the
contents of the capture buffer text. So, one can call `start-process' to
run notify-send shell command and put the actual captured text into the
notification (displayed briefly or for longer time according to the
switches passed to notify-send).

When notify-send displays notification, you can quickly eyeball if the
captured text is what you intended to capture without opening Emacs.

Hope it is more clear.

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

Re: Getting X selection reliably (Re: idea for capture anywhere in x)

[Samuel Wales]

not sure i am following everything but it seems a popup that goes away
after a very short period of time shows adequately that first contact
was made with emacs.  then, including the captured text shows that
there isn't another issue?

On 10/28/22, Ihor Radchenko  wrote:
> Max Nikulin  writes:
>
>> %(org-get-x-clipboard 'PRIMARY)
>> "
>>  :immediate-finish t)
>>
>> However to be at the safe side I would check if (org-get-x-clipboard
>> 'PRIMARY) value is not nil at first.
>
> My approach to this is simply showing a popup with captured heading
> after capture. If anything is wrong, I can quickly notice.
>
> Not sure if it is suitable for Samuel though.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
>


-- 
The Kafka Pandemic

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

Re: Getting X selection reliably (Re: idea for capture anywhere in x)

[Ihor Radchenko]

Max Nikulin  writes:

> %(org-get-x-clipboard 'PRIMARY)
> "
>  :immediate-finish t)
>
> However to be at the safe side I would check if (org-get-x-clipboard 
> 'PRIMARY) value is not nil at first.

My approach to this is simply showing a popup with captured heading
after capture. If anything is wrong, I can quickly notice.

Not sure if it is suitable for Samuel though.

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

Re: Getting X selection reliably (Re: idea for capture anywhere in x)

[Samuel Wales]

i am still lost in this and it will take me a while.  although it
would be great to have everywhere, such as in emacs also with r click,
it is not a top priority for me at this time as long as the ff
org-capture extension works [i wrote the original when it did not work
for me] beecuse ff is the biggest plaec i need it and it would make a
good backup system and i hope i did not give the impression that it is
an urgent need.

as for fluxbox, it is just the .menu file and not a tray application.
pretty straightforward.  :)

On 10/28/22, Max Nikulin  wrote:
> On 28/10/2022 15:39, Dr. Arne Babenhauserheide wrote:
>> Max Nikulin writes:
>>
>>> Then you should always have an X11 Emacs frame, maybe behind other
>>> windows
>>
>> This sounds like a tray application. Do you know whether something like
>> that already exitst (mark one frame as system tray entry)?
>
> I was trying to say that Samuel should not be affected by the case when
> X selection can not be obtained from Emacs due to absence of frames
> (terminals) having type "x".
>
>
>
>


-- 
The Kafka Pandemic

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

Re: Getting X selection reliably (Re: idea for capture anywhere in x)

[Max Nikulin]

On 28/10/2022 15:39, Dr. Arne Babenhauserheide wrote:

Max Nikulin writes:


Then you should always have an X11 Emacs frame, maybe behind other
windows


This sounds like a tray application. Do you know whether something like
that already exitst (mark one frame as system tray entry)?


I was trying to say that Samuel should not be affected by the case when 
X selection can not be obtained from Emacs due to absence of frames 
(terminals) having type "x".

Re: Getting X selection reliably (Re: idea for capture anywhere in x)

[Dr. Arne Babenhauserheide]

Max Nikulin  writes:

> Then you should always have an X11 Emacs frame, maybe behind other
> windows

This sounds like a tray application. Do you know whether something like
that already exitst (mark one frame as system tray entry)? Code the
other way round (emacs *as* system tray) seems to already exist in EXWM:
https://wiki.archlinux.org/title/EXWM#System_tray

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


signature.asc
Description: PGP signature

Re: Getting X selection reliably (Re: idea for capture anywhere in x)

[Max Nikulin]

On 28/10/2022 11:59, Samuel Wales wrote:


i launch emacs from xinit or fluxbox menu.  sometimes from a shell.  i
run emacs as a cli batch thing from a shell.


Then you should always have an X11 Emacs frame, maybe behind other 
windows, and the following command should work


emacsclient --eval '(org-capture nil "p")'

with appropriate template key name, e.g. as defined by the following 
silly example:


("p" "primary" entry
   (file "/tmp/capture-test.org")
   "* Primary
%U

%(org-get-x-clipboard 'PRIMARY)
"
:immediate-finish t)

However to be at the safe side I would check if (org-get-x-clipboard 
'PRIMARY) value is not nil at first.

Re: Getting X selection reliably (Re: idea for capture anywhere in x)

[Samuel Wales]

i do not use emacs daemon or systemd.  have not tried running emacs
from cron i think.

i launch emacs from xinit or fluxbox menu.  sometimes from a shell.  i
run emacs as a cli batch thing from a shell.

[and i run emacs on linux console when nec.  it is inaccessible for
reasons like blinking cursor.]


On 10/26/22, Max Nikulin  wrote:
> On 26/10/2022 11:58, Ihor Radchenko wrote:
>>
>> Yes. From org-capture-templates docstring:
>>
>>%x  Content of the X clipboard.
>
> Ihor, I am afraid there are a couple of pitfalls with "%x" for Samuel
> since he prefers to keep Emacs hidden so can not check result.
>
> 1. If something goes wrong, e.g. some application does not put
> highlighted text to PRIMARY selection then wrong source (CLIPBOARD) or
> empty string may be silently captured. I would prefer explicit source
> however it will not protect against stale selection from the same source.
>
> Simulate empty selection:
> echo | xsel -bi ; echo | xsel -i ; killall xsel
>
> 2. Jean pointed out that Emacs ignores X selection if it does not have
> an X frame. It was almost buried in the haystack of "SQL instead of Org"
> noise. It happens if Emacs is running as a daemon. I am unsure which way
> Samuel starts Emacs (xinit, systemd user session, systemd socket
> activation, manually, etc.)
>
> What I do not like that error text is captured and no error is returned
> to emacsclient, so checks must be performed in advance.
>
> My suggestion:
> ~/examples/org/capture-daemon.el
>  >8 
> (defun nm-check-selection (selection)
>(let ((display (org-string-nw-p (getenv "DISPLAY"
>  (if display
>  (server-select-display display)
>(error "No DISPLAY")))
>(if (org-get-x-clipboard selection)
>t
>  (error "No %S selection" selection)))
>
> (custom-set-variables
>   '(org-capture-templates
> '(("x" "%x (test)" entry
>(file "/tmp/capture-test.org")
>"* Entry
> %U
>
> %x
> "
>:immediate-finish t)
>   ("p" "primary" entry
>(file "/tmp/capture-test.org")
>"* Primary
> %U
>
> %(org-get-x-clipboard 'PRIMARY)
> "
> :immediate-finish t
>
> (require 'org-capture)
>  8< 
>
> emacs -Q -L ~/src/org-mode/lisp/ \
> -L /usr/share/emacs/site-lisp/elpa/htmlize-1.55/ \
> --daemon --load ~/examples/org/capture-daemon.el
>
> emacsclient --eval "(nm-check-selection 'PRIMARY)" \
> --eval '(org-capture nil "p")'
>
> the latter command has non-zero exit code in the case of empty selection.
>
>
>
>


-- 
The Kafka Pandemic

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