Re: A question/bug report(?)
Hi Eric,
Thanks for answering :-) I'm currently solving the issue with
#+BEGIN_export LaTeX
\begin{verbatim}[commandchars=\\\{\}]
student@juju:~$ \textbf{sudo bootstrap-juju.sh}
\end{verbatim}
#+END_export
What I was wondering is whether we could have something like:
#+ATTR_LATEX :raw t :attributes [commandchars=\\\{\}]
#+BEGIN_verbatim
student@juju:~$ \textbf{sudo bootstrap-juju.sh}
#+END_verbatim
With that ":raw t" the text between the BEGIN_ and END_ would not go
through the protecttexttt function. (of course, without the :raw t
everything would work as today).
Again, it's just because it would be a cleaner to read. I have an yasnippet
in place, so it wouldn't actually mean more or less typing.
Best, /PA
On Tue, 29 Mar 2022 at 15:12, Eric S Fraga wrote:
> I'm not sure but maybe you want to use a src block,
>
> #+begin_src latex :exports results
> ...
> #+end_src
>
> ? I am not entirely clear how you wish org to know what is "raw" and
> what is "LaTeX".
>
> --
> : Eric S Fraga, with org release_9.5.2-420-g971eb6 in Emacs 29.0.50
>
--
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler
Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
sparse TODO tree and priorities - with a custom face
I understand that org-priority-faces is only used for agenda views. However when viewing TODO items I find that the lack of additional context in the agenda view makes thinking about the TODO items more difficult. Whereas with a sparse tree the TODO items are presenting with the associated positions in the hierarchy, which is very useful for me. What I want is a way to visually see the high, medium and low priority items. For example "A", "B" and "C" items could be shown in a different color. How can I do that? Thanks for any info. -Ram
Re: citations: org-cite vs org-ref 3.0
On Tue, Mar 29, 2022 at 11:23 AM Max Nikulin wrote: ... > >> You even have managed to convince me that, besides adding missing style > >> names, some existing ones should be adjusted. noauthor/bare for citeyear > >> example makes for me much more sense ... > > > > This does need some attention, but there are wrinkles here. > > > > Citeyear is specific to author-date styles, while noauthor is intended > > to be more general. > > Anyway citation style is rather specific for a particular CSL style. I > tried some styles: > https://github.com/citation-style-language/styles/blob/master/ieee.csl > https://github.com/citation-style-language/styles/blob/master/american-physics-society.csl > nature.csl science.csl and for all these styles even "author" is > meaningless since they are numeric styles. Yes. I think it's more relevant in author-date to note styles. I believe biblatex has a command relevant here, but Denis knows biblatex better than I. > So it is not more general. Switching CSL style means necessity to update > styles in each citations (unless it is possible to specify global or > per-cite mapping). Not really. Arguably the most important style is "text", which applies to any output style; author-date, note-based, numeric. When you start getting into some of the others, the range of styles a given style may apply to shrinks. But you might say author-date styles are pretty dependent on such local citation modification. If those are output to a style that has no such notions (like a numeric one), then a processor can just ignore it. > It seems modifiers are set of boolean flags (positive "year" or negative > "suppress-author") in citeproc.el, set of values in natbib, and a kind > of hierarchy in org-cite. From my point of view, set of constrains > (flags) is the most general variant in this list. I think that's right, and is how it's represented in a GUI app like Zotero. But that's not so convenient in a plain text format. But it's a good way to explain the differences. > > I think it's probably a good idea to add "year" to the latex processors too. > > I agree. Negations are more confusing when an author needs just year. We might as well do that then, along with bibentry/fullcite. ... > I am familiar with bst language used by BibTeX and I am surprised that > initials instead of full names are not enforced by CSL styles. I'm not following here. Certainly one can specify initialization rules in a CSL style. WDYM by "enforced"? > Emphasis and bold markers may appear in plain text export. Behavior of styles > is > not uniform in respect to adding (unbreakable?) space before citation. Sorry; not following here again. Isn't the space before a citation determined by the user? Bruce
Re: Faulty SVG width in default HTML export style
Rudolf Adamkovič writes: > I now wonder if anyone knows how to fix the misaligned baselines of > inline LaTeX fragments (as shown in the second screenshot). I think we can solve this issue by looking at how Wikipedia does the alignment of text and LaTeX snippets. A cursory look at https://en.wikipedia.org/wiki/Normal_distribution ... shows that they use something like this: The alignment parameters are also dependent on the snippet itself. > If we could somehow fix that, MathJax-less export > could become usable in practice *and* it would also unlock full LaTeX > power, including TikZ and beyond! (It would also put Emacs ahead of the > pack in the world of LaTeX-capable editors because virtually every other > modern editor, including the proprietary ones, can just use MathJax.) For me, Emacs using MathJax as default came across as an unpleasant surprise: any person aware of the free/libre software movement knows that one should never allow Javascript to run in their browser: (ref https://www.gnu.org/philosophy/javascript-trap.html ). MathJax is not even compatible with LibreJS and loads script from a bunch of 3rd-party servers like Cloudflare. This enables those 3rd parties to track visitors to your website. Also, by loading external scripts, author of an website essentially puts the website and its visitors under the mercy of the script: the script, if malicious, can just sabotage the entire website. Sadly it seems that there aren't enough people using Orgmode with SVG: this CSS bug is at least present since 2020, according to git logs. Rendering SVG images is also painfully slow: I can export the document as PDF much faster than as HTML+SVG. Then there is the alignment issue. > @me.com Unrelated but I think its best to not use Apple dis-services: it has a record of kowtowing to government requests such as moving email account to surveillance-friendly regimes: https://en.wikipedia.org/wiki/ICloud#China Not to mention its utter contempt of Software Freedom such as forbidding GNU GPL on their program distribution platform. -- Yuchen Guo
Re: citations: org-cite vs org-ref 3.0
On 28/03/2022 20:16, Bruce D'Arcus wrote:
On Mon, Mar 28, 2022 at 8:37 AM Max Nikulin wrote:
John, in another message (Sun, 27 Mar 2022 13:00:40 -0400)
https://list.orgmode.org/m24k3jnq0k@andrew.cmu.edu you clearly
stated a technical limitation that is a real reason why org-cite is not
an option for you and for some other users: performance has not been
optimized for large BibTeX databases. It is deserved to be mentioned.
FWIW, Ihor posted a patch related to this a week or so ago.
I am optimistic concerning that patch since a couple of users confirmed
improvement, but it is up to John to decide if it is acceptable in
comparison to org-ref. I am unsure concerning startup time.
You even have managed to convince me that, besides adding missing style
names, some existing ones should be adjusted. noauthor/bare for citeyear
example makes for me much more sense ...
This does need some attention, but there are wrinkles here.
Citeyear is specific to author-date styles, while noauthor is intended
to be more general.
Anyway citation style is rather specific for a particular CSL style. I
tried some styles:
https://github.com/citation-style-language/styles/blob/master/ieee.csl
https://github.com/citation-style-language/styles/blob/master/american-physics-society.csl
nature.csl science.csl and for all these styles even "author" is
meaningless since they are numeric styles.
So it is not more general. Switching CSL style means necessity to update
styles in each citations (unless it is possible to specify global or
per-cite mapping).
It seems modifiers are set of boolean flags (positive "year" or negative
"suppress-author") in citeproc.el, set of values in natbib, and a kind
of hierarchy in org-cite. From my point of view, set of constrains
(flags) is the most general variant in this list.
I think it's probably a good idea to add "year" to the latex processors too.
I agree. Negations are more confusing when an author needs just year.
"Year" would be much less portable. That doesn't mean that "year"
couldn't be legitimate, in the sense of "I really need the year here".
I would say that if a citation style has no year than a warning should
be spat, but year should not appear since it is against the style.
Unsure if it is useful to have special command or style "query" that can
insert e.g. year, journal, or any other field disregarding style to
ensure that the text and the bibliography reference have not diverged,
but it is rather for descriptive text than for a citation.
But that raises another question: How will citeproc-el know where this
year is coming from, and how the year has to be formatted? That will
have to be hardcoded in the processor as styles contain no information
about this.
A fallback style (for the particular citation, for the whole document or
in global user preferences) might be specified for formatters missed in
the main style.
I have tried the following:
obt.bib:
@ARTICLE{schawlow1958iao,
author = {Schawlow, Arthur Leonard and Townes, Charles Hard},
title = {Infrared and Optical Masers},
journal = {Phys. Rev.},
year = {1958},
volume = {112},
pages = {1940--1949},
month = {Dec},
doi = {10.1103/PhysRev.112.1940},
issue = {6},
publisher = {American Physical Society},
}
obt.org:
#+bibliography: obt.bib
# #+cite_export: csl
# #+cite_export: csl
/usr/share/citation-style-language/styles/chicago-author-date.csl
# #+cite_export: csl
/usr/share/citation-style-language/styles/american-physics-society.csl
- Default: [cite:@schawlow1958iao].
- text: [cite/text:@schawlow1958iao].
- noauthor: [cite/noauthor:@schawlow1958iao].
- year/bare: [cite/year/bare:@schawlow1958iao].
#+print_bibliography:
I am familiar with bst language used by BibTeX and I am surprised that
initials instead of full names are not enforced by CSL styles. Emphasis
and bold markers may appear in plain text export. Behavior of styles is
not uniform in respect to adding (unbreakable?) space before citation.
Re: A question/bug report(?)
On Tuesday, 29 Mar 2022 at 21:44, Max Nikulin wrote: > If LaTeX is the only export target then a more simple way exists: > > #+begin_export latex Yes, of course! -- : Eric S Fraga, with org release_9.5.2-420-g971eb6 in Emacs 29.0.50
Re: A question/bug report(?)
On 29/03/2022 20:12, Eric S Fraga wrote: I'm not sure but maybe you want to use a src block, #+begin_src latex :exports results ... #+end_src ? I am not entirely clear how you wish org to know what is "raw" and what is "LaTeX". If LaTeX is the only export target then a more simple way exists: #+begin_export latex any arbitrary LaTeX code #+end_export info "(org) Quoting LaTeX code" https://orgmode.org/manual/Quoting-LaTeX-code.html
[BUG] org-agenda thinks timestamps after 23:00 correspond to the next day [9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)]
Hello, After last Saturday's hour change in Spain, org-agenda thinks that timestamps after 23:00 correspond to the next day in Emacs 29. I'm not actually sure if that is the reason, since I usually use Emacs 27, but I guess it must be that if I have found out three days after the hour change. I have tried to track down the problem, and it doesn't seem to be the fault of any org-mode code change. The problem is that (org-time-string-to-time timestamp), defined as (encode-time (org-parse-time-string timestamp)), returns different things in Emacs 27 and Emacs 29. Let's consider the timestamp "<2022-03-29 mar 23:00>" as an example: 1) (org-parse-time-string "<2022-03-29 mar 23:00>") returns (0 0 23 29 3 2022 nil nil nil). 2) (encode-time '(0 0 23 29 3 2022 nil nil nil)) returns '(25155 29520) in Emacs 27, but (25155 33120) in Emacs 29 3.1) (time-to-days '(25155 29520)) returns 738243 3.2) (time-to-days '(25155 33120)) returns 738244 4) (org-today) returns 738243 Therefore, org-agenda thinks that "<2022-03-29 mar 23:00>" is today in Emacs 27, but tomorrow in Emacs 29. `encode-time' is defined in C, and is probably system dependent, so this is probably not an org-mode bug. But maybe org-mode code could try to be smart about this? I don't know if it's even possible. And if this should not be fixed in org-mode, do you know were it should? It could be an Emacs bug? Or maybe the problem is in my system? Regards, --Ignacio Emacs : GNU Emacs 29.0.50 (build 19, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2022-03-29 Package: Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @ /home/ignacio/repos/emacs/lisp/org/)
Re: [RFC] DOCT: Declarative Org Capture Templates (easier template syntax)
On Sat, Mar 26, 2022 at 4:31 AM Ihor Radchenko wrote:
> No Wayman writes:
>
> > I'm open to bringing doct's features into Org mode, but I'd prefer
> > it not to be spread out over another two years.
>
> Proper integration of doct into org-capture.el would indeed be ideal. I
> am happy that you are ok with such option.
>
> Practically, we can do it step-by-step in separate patches:
> 1. Introduce alist format for org-capture-templates. No new
>functionality yet, just change the existing supported template
>options to :keyword value pairs. Also, make sure that we keep
>backwards compatibility.
> 2. Extend the alist with new options, like ${keyword} expansion, hooks,
>contexts, children, etc Maybe in a sequence of patches.
> 3. Provide validation of capture templates.
>
> WDYT?
>
> Best,
> Ihor
>
I'll just say that I would be an enthusiastic adopter of the new syntax
(just one data point). I agree wholeheartedly that named properties in
plists are much easier to remember and adjust than positional arguments,
especially when there are lots of the latter. So, I hope this move
sforward.
Re: A question/bug report(?)
I'm not sure but maybe you want to use a src block, #+begin_src latex :exports results ... #+end_src ? I am not entirely clear how you wish org to know what is "raw" and what is "LaTeX". -- : Eric S Fraga, with org release_9.5.2-420-g971eb6 in Emacs 29.0.50
