org-capture does not capture from certain pages
i find that if i use html gmail[*], i can capture using the org-capture extension in firefox, and i will get page title [which is email subject] and selected text. this is glorious. if i do the same from emails sent to a disroot.org address, it captures only like * [[https://webmail.disroot.org/?_task=mail&_mbox=INBOX][Disroot webmail :: Inbox]] i wonder if this is fixable? disroot uses js. [*] html gmail is horrifyingly going away soon, and for those who'd like me to de-google, every time i use google takeout, it fails to download my emails. -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
Re: bash source code block: problem after ssh commands
Ihor Radchenko writes: > Bruno Barbier writes: > >> FWIW, M-x shell differs from what a plain terminal is doing (xterm, in >> my case), but, I do prefer 'M-x shell' behavior: it allows me to copy >> multiple lines, getting the same results as when I type them manually, >> or copy them line by line. My xterm doesn't seem to allow me to do that. > > The behavior of M-x shell can indeed be made use of. > However, this particular difference with xterm, AFAIU, is not > documented - unaware users may be surprised. > The situation is worse with Org shell blocks - users naturally expect > script-like behavior (even for :session), but run into edge cases like > this and get confused. > > We should either document the caveats, or, preferably, make the behavior > more consistent with expectations. At least, by default. > That's why I think that filing a bug report makes sense from Org mode > project point of view. Thanks for the explanation. I see you got my point. We'll see what Emacs maintainers will say about the current behavior of M-x shell; filling the bug report was definitely a good idea anyway. Ihor Radchenko writes: > __By default__, Org should produce more expected behavior - what users > would get from running a script file rather than from redirecting stdin. > We can optionally leave the stdin redirection as an option to be used by > the users who understand the peculiarities. I agree that it would be simpler to switch to the script-like behavior by default on org side. About the interactive-like behavior, that would be nice to keep it, if some people rely on it in their existing documents (I personally don't). Bruno
Re: Non-emacs shell (Re: bash source code block: problem after ssh commands)
Hi Max, Max Nikulin writes: > On 17/11/2023 22:47, Bruno Barbier wrote: >> FWIW, M-x shell differs from what a plain terminal is doing (xterm, in >> my case), but, I do prefer 'M-x shell' behavior: it allows me to copy >> multiple lines, getting the same results as when I type them manually, >> or copy them line by line. My xterm doesn't seem to allow me to do that. > > I am unsure what do you expect from xterm, but perhaps it is not > responsibility of a terminal application. It has been said in this thread that 'M-x shell' should be fixed to match the behavior that we see in a plain terminal, when we copy multiple lines. I just wanted to point out that I do prefer the way 'M-x shell' handles the copy of multiple lines. > Multiple lines can be copied to regular BASH prompt (bracketed paste is > enabled by default nowadays), however it may be inconvenient to edit. > You may use edit-and-execute-command (C-x C-e) (BASH, not Emacs key > binding) to start an editor and to paste multiple commands there. > See also "fc" BASH built-in for editing and re-executing last commands. Thanks Max! I didn't know that. I should definitely start using this when I'm stuck in a console, to safely copy/edit my commands using Emacs. Thanks, Bruno
