Re: Fwd: Help with my first elisp
Ypo, > > but, using whatever the name of the logos-focus mode map, pointing at > > your functions? ... > I think "logos" doesn't have a map, is it possible? certainly possible (i don't use logos). in fact, https://gitlab.com/protesilaos/logos/-/blob/main/logos.el has the lines ;; Logos does not define any key bindings. Try something like this: ;; ;; (let ((map global-map)) ;; (define-key map [remap narrow-to-region] #'logos-narrow-dwim) ;; (define-key map [remap forward-page] #'logos-forward-page-dwim) ;; (define-key map [remap backward-page] #'logos-backward-page-dwim)) ;; ;; By default those key bindings are: C-x n n, C-x ], C-x [. which certainly implies no map. and, iiuc, *these* =define-key= lines are global, i.e., remain true whether you are in, or out of, logos mode. cheers, Greg
Re: Help with my first elisp
maybe use something like >/> (define-key mh-letter-mode-map/ >/> (kbd "C-c s")/ >/> 'ggm-mh-sentaddrs-completion)/ but, using whatever the name of the logos-focus mode map, pointing at your functions? Hi Greg I think "logos" doesn't have a map, is it possible? On Mon, May 23, 2022 at 09:46:09AM -0700, Greg Minshall wrote: >/Ypo,/ >// >/> (defun salto ()/ >/> (interactive)/ >/> (if posicion 1/ You are comparing the value of posicion to 1? Then it should probably be "(if (= posicion 1) ...)" or "(if (equal posicion 1) ...)" or something like that. Cheers -- t Thanks, Tomas. It seems the "if" part works, now I use my elisp just with the spacebar :-) (add-hook 'logos-focus-mode-hook #'(lambda () (defvar posicion "Position where is the cursor.") (defun focusPointStart () (interactive) (next-line 1) (beginning-of-visual-line) (forward-char 6) (setq posicion 1) ) (defun focusPointInter () (interactive) (forward-char 23) (setq posicion 2) ) (defun focusPointEnd () (interactive) (end-of-visual-line) ;;C-e (backward-char 7) (setq posicion 3) ) (defun focusJump () (interactive) (if (equal posicion 1) (focusPointInter) (if (equal posicion 2) (focusPointEnd) (if (equal posicion 3) (focusPointStart) (define-key global-map (kbd "SPC") #'focusJump) ))
Re: Question Regarding Easier Issues To Help With
"Samuel Banya" writes: > Its kind of funny since all I do at work doing tech support is reproducing > stuff for Devs, but I guess that works in this context too. I just didn't > want to have to do more tech support, and wanted to get into the nitty gritty > of Elisp to be honest. More so, to get Dev experience so that I can finally > move away from tech support and into a Dev job later (after I finish my web > dev bootcamp first though). If you prefer to do something programming-related, some of the provided links also offer such possibility. Or you can reproduce a bug and then also fix it ;) Further, you can contribute to Org testing suite. Just look at testing/ folder and look at the existing tests. You can add some new edge cases to the tests or create new tests for interactive Org functions not yet covered by the tests (there are plenty). Also, See https://orgmode.org/list/874k81bsvz.fsf@localhost Finally, I may host another meetup this Saturday where we can discuss Org development/bug fixes live, possibly with screen sharing. Best, Ihor
Re: Question Regarding Easier Issues To Help With
Thanks Tim and Ihor, that really puts the "What" to focus on into perspective. I put this in my Org notes and will take a look at the items you mentioned. Its kind of funny since all I do at work doing tech support is reproducing stuff for Devs, but I guess that works in this context too. I just didn't want to have to do more tech support, and wanted to get into the nitty gritty of Elisp to be honest. More so, to get Dev experience so that I can finally move away from tech support and into a Dev job later (after I finish my web dev bootcamp first though). However, both posts are really really good, and I will use them to my advantage when I get some free time on the weekend to gauge what issues are easiest to tackle. Most likely, I will bother the mailing list when I get a shortlist of like 3 of them if I come across any issues though I'll try to find what I can given the codebase itself first. Thanks so much again for this, gives me the motivation to really do it. Sincerely, Sam On Mon, May 23, 2022, at 5:03 AM, Ihor Radchenko wrote: > "Samuel Banya" writes: > > > Hey there, > > So I took a look at the following link recently as I finally have had time > > again over the past couple of months since I've been dealing with a lot of > > personal family stuff, and got some time back again. > > Thanks for your interest in contributing! > > > Can anyone lead me in the right direction for some beginner tier issues to > > take a look at, as well as hand holding for any workflow on how to actually > > work on the related issue / source code accordingly: > > https://updates.orgmode.org/#help > > Here is a list that might be helpful. Not all the issues are easy there. > Mostly, something I quickly judged as easy/important or unanswered. > Also, there are not only bug reports, but also patches that someone > needs to test with various edge cases. > > https://orgmode.org/list/UT6T2iOXtO0dMWc5QA4ZPbG0yh-4wOprgsHAe91c_wf7DwDKdLoJilTWK50rJuz8cNxtwrlTc_CpQIGBpQixTjDPnCJfq-WQKhk4oFLed_I=@protonmail.com > https://orgmode.org/list/ty2pr0101mb3693187b93665e208637f6c8da...@ty2pr0101mb3693.apcprd01.prod.exchangelabs.com > https://orgmode.org/list/ca+3amhehg_tgcmz1mmy0hpsaw3hqokpnfcjboaozzaxnjcz...@mail.gmail.com > https://orgmode.org/list/87imnypcvk@iki.fi > https://orgmode.org/list/87mu3djf4u@gmail.com > https://orgmode.org/list/87woky8sam@norang.ca > https://orgmode.org/list/cajcao8t_sfascks4fovnbt5rrsivfr1z15jemh2rgonz_ha...@mail.gmail.com > https://orgmode.org/list/lotcjav--...@keemail.me > https://orgmode.org/list/87sfxiw2jp@posteo.net > https://orgmode.org/list/dd0ae51d-7d56-0ff6-5eb1-3786464ad...@arfer.net > https://orgmode.org/list/5a1cb629-8437-41f5-fd75-674c949ea...@gmx.at > https://orgmode.org/list/CAOn=hbefyj7edw6gsobqgkofm65bx1cdc_inxaisdpv74kw...@mail.gmail.com > https://orgmode.org/list/87v91vle4u@gmail.com > https://orgmode.org/list/87wnl53cq4.fsf@localhost > https://orgmode.org/list/so2fh1$10kj$1...@ciao.gmane.io > https://orgmode.org/list/041ca43d-2efb-db1e-76ab-7c15af088...@posteo.eu > https://orgmode.org/list/CAJr1M6d=0qtynpwabwbnciq2fm4mcybrxoer_hr-va4tj1k...@mail.gmail.com > https://orgmode.org/list/20171014123248.51568eec@Tourifreet > https://orgmode.org/list/paxpr06mb7760da356c7c27045beb64f6c6...@paxpr06mb7760.eurprd06.prod.outlook.com > https://orgmode.org/list/87a6gdaa9i.fsf@tsdye.online > https://orgmode.org/list/cab14nk88cyihdgkdqzxhnjyekp_bzz_1j73p-y2fgsk_7jt...@mail.gmail.com > https://orgmode.org/list/cafyqvy3mxi4drts+w-ax7bfelvujqh4dodeypy3hygrrume...@mail.gmail.com > https://orgmode.org/list/87mthrtb5u@alphaville.usersys.redhat.com > > > I ask because I'm a bit of an Elisp newbie. I'm assuming the first step is > > to try to reproduce the bug given the user's info, and then attempt to look > > at the codebase to see what might be causing it? > > Without elisp, you can > 1. Try to reproduce bugs and give detailed instructions for maintainers >to fix (it is much easier to fix bugs with detailed steps how to >reproduce them) > 2. Try submitted patches and see if they work on your customized Org. >Then, report any issues > 3. Monitor websites like stackexchange and reddit and transfer bug >reports from there to the mailing list. > > Also, I recorded a video explaining how to reproduce Org mode bugs in > https://open.tube/videos/watch/4d819114-43bf-42df-af94-f94fc53dd0d9 > > Best, > Ihor >
Re: Fwd: Help with my first elisp
On Tue, May 24, 2022 at 07:32:31PM +0200, Ypo wrote: [...] > Thanks, Tomas. It seems the "if" part works, now I can use my elisp just > with the spacebar :-) Glad it worked :) Cheers -- t signature.asc Description: PGP signature
Fwd: Help with my first elisp
maybe use something like >/> (define-key mh-letter-mode-map/ >/> (kbd "C-c s")/ >/> 'ggm-mh-sentaddrs-completion)/ but, using whatever the name of the logos-focus mode map, pointing at your functions? Hi Greg I think "logos" doesn't have a map, is it possible? On Mon, May 23, 2022 at 09:46:09AM -0700, Greg Minshall wrote: >/Ypo,/ >// >/> (defun salto ()/ >/> (interactive)/ >/> (if posicion 1/ You are comparing the value of posicion to 1? Then it should probably be "(if (= posicion 1) ...)" or "(if (equal posicion 1) ...)" or something like that. Cheers -- t Thanks, Tomas. It seems the "if" part works, now I can use my elisp just with the spacebar :-) (add-hook 'logos-focus-mode-hook #'(lambda () (defvar posicion "Position where is the cursor.") (defun focusPointStart () (interactive) (next-line 1) (beginning-of-visual-line) (forward-char 6) (setq posicion 1) ) (defun focusPointInter () (interactive) (forward-char 23) (setq posicion 2) ) (defun focusPointEnd () (interactive) (end-of-visual-line) ;;C-e (backward-char 7) (setq posicion 3) ) (defun focusJump () (interactive) (if (equal posicion 1) (focusPointInter) (if (equal posicion 2) (focusPointEnd) (if (equal posicion 3) (focusPointStart) (define-key global-map (kbd "SPC") #'focusJump) ))
Re: [PATCH] Avoid ignoring LaTeX export output errors when org-latex-pdf-process is a list
On 22/05/2022 10:51, Ihor Radchenko wrote: The attached patch is fixing a rather annoying problem when org-latex-pdf-process is set to a list. Currently, only output of the last command in the list is preserved in *Org PDF LaTeX output* buffer, which sometimes prevents ox-latex from detecting compilation warnings. I may be wrong, but I believed that some code might check buffer content for specific messages to determine if additional pass is required to resolve or adjust cross-reference links. If it is done by external tools working with log files than there is no problem, otherwise lisp code analyzing whole buffer may be confusing by first pass messages when there was no e.g. .aux file. Erasing messages from previous commands making debugging of problems harder, so having complete logs should be an improvement.
Re: About 'inline special blocks'
On 24/05/2022 09:51, Timothy wrote:
To me, this is another reason for comment and #+attr_X lines not to break
paragraphs, as then we can just re-use #+attr_X lines.
I like the idea that comments and attribute lines should not be
paragraph separators. I expect, it should alleviate the issue that LaTeX
and Org paragraphs may significantly differ. Do somebody has examples
when such change will cause negative effects (besides broken
compatibility, of course)?
┌
│ Hi there look at
│ #+attr_X: :prop val
│ inline_mark{some content}
│ and now continuing the paragraph...
└
However I am afraid that using the same construct for block-level
elements and inline object will cause confusion. Consider a paragraph
starting from a link. Which attributes belongs to the whole paragraph
and which ones should affect the starting link only?
I consider attributes specific to an inline object as a great feature,
but I am unsure if it requires special inline object. Would not it be
enough to allow attributes for already existing objects (emphasis,
links, citations)? It is feasible to require from external tools such as
pandoc to support special blocks (likely implemented in lisp code)?
Concerning fear that complicated attributes makes text hardly readable,
macros might be a rescue, but it would depend on implementation.
I had an idea to implement proof-of-concept for inline attributes using
a special link type and a parse tree filter that transfers attributes to
the next object. Unfortunately time related bugs in Emacs appeared to be
rather time consuming.
>8
#+macro: nofollow [[attr:(:html (:rel "nofollow noopener"))]]
An {{{nofollow}}[[attr:(:html (:title "be
careful!"))]][[http://unsafe.com][unsafe link]].
8<
Such implementation would allow to test if it convenient enough and
whether special blocks are really necessary.
Re: About 'inline special blocks'
On Tue, May 24 2022 11:56, Ihor Radchenko wrote:
> I think that we might simply allow to define complex configuration
> before the containing paragraph. Something like:
On that note, I think that allowing for inline special blocks would make
that more readable. It would work wonderfully with
org-special-block-extras [1], where the user could define complex blocks
with formatting configuration and what-not, and just use that as an
inline block.
> #+attr_latex[name]:
> Vestibulum convallis, lorem blockname_[<>]{text} a tempus semper, dui
> dui euismod elit, vitae placerat urna tortor vitae lacus.
>
> "<>" will be treated as "" during
> export/parsing.
Although I do agree that this sort of solves the same problem as the
other approach, but I, personally, find that defining new special blocks
is not only easier to reuse, but more readable as well. But I'm thinking
in terms of org-special-block-extras here, so take my 2 cents with a
grain of salt.
[1] https://github.com/alhassy/org-special-block-extras
Best,
--
João Pedro de Amorim Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Re: problem with unwanted strikeout in src blocks
>>> "JJ" == Jeremie Juste writes:
> Hello Uwe
>> On Monday, 23 May 2022 at 19:24, Uwe Brauer wrote:
> Sorry I don't have matlab and I have never used the solutionorbox
> environment, but I believe you can generate latex directly. For example
> with R I can to the following.
> #+begin_src R :exports results :eval yes :results output latex
> cat("\\begin{align*}")
> cat("P(\\text{Covid19}|\\text{ + })&=\\frac{P(\\text{ +
> }|\\text{Covid19})P(\\text{Covid19})}{P(\\text{ + } |
> \\text{Covid19})P(\\text{Covid19}) + P(text{ +
> }|\\text{No-Covid19})P(\\text{No-Covid19})}")
> cat("\\end{align*}")
> #+end_src
Yes but I need the solutionbox since I don't want to convert to vanilla latex,
but to the exam class.
smime.p7s
Description: S/MIME cryptographic signature
Re: problem with unwanted strikeout in src blocks
>>> "IR" == Ihor Radchenko writes:
> Uwe Brauer writes:
>> However when I wrap a solutionorbox around it (which I need when
>> exporting to latex) all text between the «+»
>> gets a strikeout.
>>
>>
>> #+begin_solutionorbox
>> #+begin_src matlab :exports results :eval never-export :results output latex
>> disp('P(\text{Covid19}|\text{+})&=\frac{P(\text{+}|\text{Covid19})P(\text{Covid19})}{P(\text{+}|\text{Covid19})P(\text{Covid19})+P(\text{+}|\text{No-Covid19})P(\text{No-Covid19})}\\')
>> #+end_src
>> #+end_solutionorbox
>>
>> And idea what to do?
> This is a known bug in Org fontification. The fix is not trivial. WIP.
> See https://orgmode.org/list/87ee7c9quk.fsf@localhost
Aha, thanks!
> Current development version of the fix is in
> https://github.com/yantar92/org/tree/feature/org-font-lock-element, but
> it is not yet complete and will require a lot more work.
Ok right now this is not so important for me. I might give it a try some
other time, just for testing proposes.
> Note that other than the visual appearance, your code block is not
> affected. That is, export will work just fine. No strike-through will
> be present.
That I assumed already, still it is a bit annoying, but then not that
important I say.
smime.p7s
Description: S/MIME cryptographic signature
Re: re-scanning bibliography for org-cite
On Wednesday, 3 Nov 2021 at 17:21, Nicolas Goaziou wrote: > oc-basic relies on a cache. The cache key contains a hash of the > contents of the bib file. So whenever the bib file is modified, the > cache is invalidated, and oc-basic parses again the file. > > IOW, rescanning happens automatically in oc-basic. Hi Nicolas, sorry to revisit this but I continue to run into the problem of the bibliography not being rescanned automatically. What is the easiest way (other than leaving Emacs and restarting) to force it, assuming there is one? I.e. maybe I can invalidate or clear the cache? I do not know why rescanning doesn't happen. It usually does but then sometimes it doesn't without any noticeable difference in the actions I have taken. Frustrating. I hate restarting Emacs... ;-) Thank you, eric -- : Eric S Fraga, with org release_9.5.3-511-g8e69ad in Emacs 29.0.50
Re: Default attributes for images in beamer export
On 2022-05-23 10:59, Timothy wrote: Hi Eric, But given that you also want to keep the aspect ratio, I am curious as to why you would need/want to specify both? Just on this, the `keepaspectratio' option of `graphicx' could be relevant here. All the best, Timothy Thanks. Yes, I think that Eric is asking about why I have the three options set already: width, height and keepaspectratio. In my experience, sometimes, my slide is too narrow (as compared to wide) and other times, it is too short (as compared to high). Since I don't want to be dealing with which one is going to work the best, I just set the three options to forget about them (as a default), and usually the smallest size will kick in (which is the safest for my slides). So, for example, even if I explicitly say that I want a specific width, it may be that the height works better and LaTeX (Beamer) is lenient with me. I am not saying that it makes sense, it's just what I use :P . - This free account was provided by VFEmail.net - report spam to ab...@vfemail.net ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options!
Re: org-clock idle time in pgtk Emacs
Julien Cubizolles writes:
> org-clock checks for the 'x window-system in order to use the program
> set up by org-clock-x11idle-program-name. Recent Emacs versions use the
> 'pgtk instead of 'x and as such will default to using
> org-emacs-idle-seconds in org-user-idle-seconds.
>
I"m not sure this is accurate. You should only use the pgtk build of
Emacs if your running wayland. You definitely should not use it if your
running under X.
The big issue is that some important key input facilities don't work
correctly if you run the pgtk build under X (actually, I'm not sure they
work correctly under Wayland either, but then again, Wayland is a
different beast to X and differences can be expected).
The pgtk build is not a replacement for the current xlib+gtk build,
which will remain the correct build when running under X.
Unfortunately, this does mean that if you use both X and Wayland, you
likely will need two builds of Emacs.
There was a fairly long discussion thread about this on emacs-devel
about a month or so ago. The upshot was flagging the need to update the
documentation to clarify that people should not use the pgtk build when
running under X windows.
I suspect this means the below patch will need further refinement.
> The following patch provides a crude workaround.
>
> I'm using a python program (included below) to report idletime in
> wayland, using the idle-time module. It can be used for
> org-clock-x11idle-program-name.
>
> modified lisp/org-clock.el
> @@ -1196,7 +1196,7 @@ If `only-dangling-p' is non-nil, only ask to resolve
> dangling
>
> (defvar org-x11idle-exists-p
>;; Check that x11idle exists
> - (and (eq window-system 'x)
> + (and (or (eq window-system 'pgtk) (eq window-system 'x))
> (eq 0 (call-process-shell-command
>(format "command -v %s" org-clock-x11idle-program-name)))
> ;; Check that x11idle can retrieve the idle time
> @@ -1213,7 +1213,7 @@ This routine returns a floating point number."
>(cond
> ((eq system-type 'darwin)
> (org-mac-idle-seconds))
> - ((and (eq window-system 'x) org-x11idle-exists-p)
> + ((and (or (eq window-system 'x) (eq window-system 'pgtk))
> org-x11idle-exists-p)
> (org-x11-idle-seconds))
> (t
> (org-emacs-idle-seconds
>
> #!/usr/bin/env python3
>
> from idle_time import IdleMonitor
>
> monitor = IdleMonitor.get_monitor()
> print(f"{1000*monitor.get_idle_time():.0f}")
org-clock idle time in pgtk Emacs
org-clock checks for the 'x window-system in order to use the program
set up by org-clock-x11idle-program-name. Recent Emacs versions use the
'pgtk instead of 'x and as such will default to using
org-emacs-idle-seconds in org-user-idle-seconds.
The following patch provides a crude workaround.
I'm using a python program (included below) to report idletime in
wayland, using the idle-time module. It can be used for
org-clock-x11idle-program-name.
--8<---cut here---start->8---
modified lisp/org-clock.el
@@ -1196,7 +1196,7 @@ If `only-dangling-p' is non-nil, only ask to resolve
dangling
(defvar org-x11idle-exists-p
;; Check that x11idle exists
- (and (eq window-system 'x)
+ (and (or (eq window-system 'pgtk) (eq window-system 'x))
(eq 0 (call-process-shell-command
(format "command -v %s" org-clock-x11idle-program-name)))
;; Check that x11idle can retrieve the idle time
@@ -1213,7 +1213,7 @@ This routine returns a floating point number."
(cond
((eq system-type 'darwin)
(org-mac-idle-seconds))
- ((and (eq window-system 'x) org-x11idle-exists-p)
+ ((and (or (eq window-system 'x) (eq window-system 'pgtk))
org-x11idle-exists-p)
(org-x11-idle-seconds))
(t
(org-emacs-idle-seconds
--8<---cut here---end--->8---
--8<---cut here---start->8---
#!/usr/bin/env python3
from idle_time import IdleMonitor
monitor = IdleMonitor.get_monitor()
print(f"{1000*monitor.get_idle_time():.0f}")
--8<---cut here---end--->8---
--
Julien Cubizolles
Re: About 'inline special blocks'
On Tuesday, 24 May 2022 at 10:51, Timothy wrote: > To me, this is another reason for comment and #+attr_X lines not to > break paragraphs [...]. And, in fact, if this were true (which I would like), I personally would see no reason for having inline special blocks. Just my 2¢. -- : Eric S Fraga, with org release_9.5.3-511-g8e69ad in Emacs 29.0.50
