Re: [O] org-store/insert-link truncating the full subject of mails
Hi, Nicolas Goaziou writes: > I don't know. This is why I agree it is safer to limit length to an > arbitrary number instead of allowing any size. Hoping to find an actual answer, I did a =git blame lisp/org.el= and found the commit that introduced it, 2c16f092e64915a7e3d0b2dda82f3978a0f42dea, by Carsten Dominik, the creator of Org mode himself. I emailed Carsten yesterday and asked if he recalls why he introduced that variable and that behvaiour. He said that he doesn’t recall exactly, but that either it was aesthetic (he didn’t find extremely long link descriptions pretty), or that long lines slowed down some regular expressions that ran in the buffer. He said it was most likely the first one (aesthetic), and that he wouldn’t object to lifting the restriction. On a side note, I’d like to point out that I use C-h k, C-h f, and C-h v many times a day, especially when encountering new functions or variables. But I don’t know if I’m the minority, or if most other Emacs users check the docs frequently as well. That said, I still find the default a bit obtuse and frankly unexpected. I don’t know, maybe a nice middle ground between the current behaviour and completely removing the limit would be to increase the limit from 30 to 78 characters, the recommended maximum number of characters in a line according to RFC 2822 [0]. That somehow feels less arbitrary, and would cover a larger portion of subjects. [0]: https://tools.ietf.org/html/rfc2822#section-2.1.1 > I updated the manual instead. It now mentions > `org-email-link-description-format'. Thanks for that. Best, amin
[O] Custom Org-Beamer Frame
Hey,
I'm using org-mode 9.1.9 to prepare my slides. I'm using mtheme [1], a
modern LaTeX beamer theme. This theme supports frame footer, which is
sometimes handy if you would like to add a reference to a slide. In the
following, you will find an example use case:
,
| {%
| \setbeamertemplate{frame footer}{My custom footer}
| \begin{frame}[fragile]{Frame footer}
| Example
| \end{frame}
| }
`
I would like to archive this with org-mode with a special
environment. However, it seems that org-beamer-environments-extra only
works with headlines greater than org-beamer-frame-level. Is there any
other way to archive this? I would like to have something like this:
,
| * Section
| ** Frame
| :PROPERTIES:
| :BEAMER_env: footer
| :BEAMER_envargs: My custom footer
| :END:
|
|- Example
`
Thanks in advance!
Cheers
Links:
[1] https://github.com/matze/mtheme
--
Dr. Florian Adamsky
https://florian.adamsky.it/
Re: [O] org-store/insert-link truncating the full subject of mails
Le 28/10/2018 à 10h05, Amin Bandali a écrit : > Hi, > > Nicolas Goaziou writes: > >> I don't know. This is why I agree it is safer to limit length to an >> arbitrary number instead of allowing any size. > > Hoping to find an actual answer, I did a =git blame lisp/org.el= > and found the commit that introduced it, > 2c16f092e64915a7e3d0b2dda82f3978a0f42dea, by Carsten Dominik, > the creator of Org mode himself. > > I emailed Carsten yesterday and asked if he recalls why he > introduced that variable and that behvaiour. He said that he > doesn’t recall exactly, but that either it was aesthetic (he > didn’t find extremely long link descriptions pretty), or that > long lines slowed down some regular expressions that ran in the > buffer. He said it was most likely the first one (aesthetic), > and that he wouldn’t object to lifting the restriction. Thank you so much! That was the Right Thing to do imho. I really have to learn git. I wish a knew it here. > On a side note, I’d like to point out that I use C-h k, C-h f, > and C-h v many times a day, especially when encountering new > functions or variables. But I don’t know if I’m the minority, or > if most other Emacs users check the docs frequently as well. I’m an heavy user of them as well, and find them way easier and more friendly than the manual, as they usually, don’t require me to read more than a paragraph of a few lines (or it’s me doing it repetedly then), while a manual requires to prepare to read a text of an indefinite length (before to have found) which is way less predictable and hence more tiring. The problem is, ideally identifiers should be easily named so that you easily find them with correct prefixes and autocompletion, but you don’t always know/think to the right keywords, and the words are not always in the most practical order. Most of time it works, so it stays awesome and extremely useful, but it stays imperfect, and henc is not a substitute for better defaults. > That said, I still find the default a bit obtuse and frankly > unexpected. I don’t know, maybe a nice middle ground between the > current behaviour and completely removing the limit would be to > increase the limit from 30 to 78 characters, the recommended > maximum number of characters in a line according to RFC 2822 [0]. > That somehow feels less arbitrary, and would cover a larger > portion of subjects. Rather cutting it, I’d rather try to find the gnus function that cut subject lines so it does more semantically (like, removing the entire Was: part if it doesn’t fit, rather than cutting it in the middle), but 78 seems totally more reasonable, at worse, indeed: but maybe that aforementioned gnus function does something related to it (maybe it does cut when it exceed 78 chars?)? However I was unable to find it by el-searching for "was:?", so I’ll ask them directly, hoping they know and answer.
[O] org-email-link-description-format (Was: Re: org-store/insert-link truncating the full subject of mails)
On 2018-10-28 at 10:05, Amin Bandali wrote: > That said, I still find the default a bit obtuse and frankly > unexpected. I don’t know, maybe a nice middle ground between the > current behaviour and completely removing the limit would be to > increase the limit from 30 to 78 characters, the recommended > maximum number of characters in a line according to RFC 2822 [0]. > That somehow feels less arbitrary, and would cover a larger > portion of subjects. > > [0]: https://tools.ietf.org/html/rfc2822#section-2.1.1 Okay, so I did not read carefully enough: this is a per line limit, however Gnus already include this limitation in fill-column so that to fold subject line in several lines that will be no more than 78 characters, there’s no need to limit to 78 characters, and indeed I sometimes end with subject lines of more than one line, and wouldn’t like to see my normal subject line truncated. The same way, org-mode will naturally see its paragraphs filled if wanted by the user (otherise there are no problems in long lines, except, afaik, by default, it disable truncating lines). On 2018-10-28 at 18:01, Garreau, Alexandre wrote: > Rather cutting it, I’d rather try to find the gnus function that cut > subject lines so it does more semantically (like, removing the entire > Was: part if it doesn’t fit, rather than cutting it in the middle), but > 78 seems totally more reasonable, at worse, indeed: but maybe that > aforementioned gnus function does something related to it (maybe it does > cut when it exceed 78 chars?)? > > However I was unable to find it by el-searching for "was:?", so I’ll ask > them directly, hoping they know and answer. So the function I was searching is `message-strip-subject-trailing-was', and only strip the was part, it doesn’t conditionally strip “Was” if there were several, or if the subject line was too long. Yet it can be used for org-mode as the “Was:” trailing part is likely not to be interesting at all for refering to a particular message, as anyway it will be found again when visiting the said article. What’s more interesting is it’s used in a function `message-simplify-subject', calling a customizable list of functions (`message-simplify-subject-functions'), that will simplify deeply the subject, removing also the “Re:”, the mailing-list part, encoded parts, etc. Yet, as it currently only used for replying, it seems to, wrongly imo, add a “Re:” to the subject line (while this should be its scope, imo). So this one is not usable as is. But `message-strip-subject-re' might be used per se itself, otherwise, as it seems to me the “Re:” might not be interesting as well, though mailing-list part may be useful, as in `org-email-link-description-format' there is nothing to refer to the group (either the group name in gnus, or either content of “Newsgroups” header or mailing-list (content of “List-id” or “List-post”, either address or human-readable part)), but not all mailing-list embed one, so it might bring inconsistency, and adding a said new format-specifier to `org-email-link-description-format' seems to me preferable (why not “%g” for “group”?). So may I suggest to change `org-email-link-description' and update `org-email-link-description-format', so that to support a "%g" specifier, to refer to the content of :group (or should we add something to refer List-ID/List-Post?), and a %S that’d return the subject, simplified by `message-strip-subject-trailing-was', `message-strip-subject-trailing-re', or, maybe rather, by all the functions inside `message-simplify-subject-functions' (waiting for `message-simplify-subject' to be corrected).
Re: [O] *markup*, /markup/ and _markup_ true semantics [Was: Re: Ox-html: Replace with and with ]
On reading your response, we are probably not as far apart as I first thought. However, we have now wondered into discussion which probably isn't appropriate for this list. It is now in the realms of something that would probably be better discussed with a good bottle of red or a nice cold beer! There is lots that is 'broken' with the web and I suspect much of it we will just have to live with and hope whatever the next evolution brings us learns from our mistakes. Tim Garreau, Alexandre writes: > On 2018/10/27 at 07:15, Tim Cross wrote: >> I have either misunderstood most of your position or I simply disagree >> with it - I'm not sure which. > > maybe a mix of both? I hope it’s a misunderstandnment but if it’s not I > want to understand too so to get to a constructive agreement. > >> - Much of what you argue seems to be based around ideas associated with >> typography. IMO this is where things fall down. Typography is really >> only relevant to 'printing' (either on paper or screen). Markup is not >> just about printing - it is about conveying what the author wanted and > > Indeed. But many people do not abstract what they mean to write and > still (often, poorly) think in terms of “italic” and “bold” (the org > manual, as you later said, even do so). What I wanted to underline is > that both “italic” and “bold” (and underline too somewhat) are not just > arbitrary display-level caracteristic that had the particularity to > later get a meaning: *first* a *meaning* was wanted, and *then* they > were invented as an imperfect, more or less good, way to translate these > meanings or their intents to display (it’s as imperfect as a bitmap or > handwriting of a circle, or a sampled and compressed audio, is to the > bezier curve or equation of a circle which resulted in it, or the > function that produced the audio (such as a LilyPond musical partition > or a resulting MIDI file)). > > I’m willing to extract as much of the original meaning (be it about > attention, memorization, structuration, etc. (very abstract cognitive > human features are still more common than visual-recognition features)) > so it can be then better applied everywhere, without the burden and > constraints of the original media (display), with a little of history > because I like to rehistoricize things into their material and social > background, so not to see them as a static, ahistoric, uncreated, > uncriticizable, concept. Concepts and tools are made for people to > serve them, not the opposite. > >> how that is best interpreted will depend on the media being used >> (i.e. how the content is 'rendered') and should largely be up to the >> consumer. > > Yes totally, this is why I believe we, at best, should try to give clear > and defined meaning to why do we use *, / and _-tags, rather than just > translating them to the traditional , , and tags, that > were actually just a poor 1-to-1 wrapping to the old , and > tags, which had no meaning, and still have confused, complex and not > backward-compatible meaning. > > And why sometimes it might be better to set up user options, so if > authors disagree with what is meant by their tags, they can change it, > so in the end that gives the correct semantic markup and everybody will > get the same, intended, meaning. > > Also why, ideally, for the web, I wished server-side CSS never existed > and we only used it as a user-customization language (but still most > websites have poor semantic tagging, and complex tags composition have > still no clear defined meaning so it the end it becomes either guessing, > either a request to add yet-another tag to the already complex HTML > spec). > >> - I am a screen reader user. While you are correct that pitch, tone, >> speed and different voices are often used to convey things like 'bold' >> or 'italic', there is no universally accepted rule for this >> interpretation, at least not in the same sense as there is with >> typography. > > I know, that’s why I wanted to check with Orca, NVDA, and maybe Jaws too > if I could. > >> We all know what bold or italic looks like, but there is no >> agreement as to what these should sound like. When you use Jaws, you >> will get a different result from when you use Orca or Emacspeak or >> Window Eyes or However, this shouldn't really matter - how >> these are 'rendered' should ideally be under the control of the >> individual consuming the content. When I consume a document, it >> should be my decision as to how the content is presented and for me, >> interpreting 'strong' or 'emphasis' seems to be far clearer than >> 'bold' or 'italic'. > > That’s why I’d like * and / to get better meaning than bold and italic. > For me it is already widely accepted that * is, sometimes, considered as > bold, but more widely used for emphasis. So it should be considered as > such (and, personally, I’ve meant this so that it could begin rendering > with italic on display for ins
Re: [O] *markup*, /markup/ and _markup_ true semantics [Was: Re: Ox-html: Replace with and with ]
Tim Cross writes: > On reading your response, we are probably not as far apart as I first > thought. However, we have now wondered into discussion which probably > isn't appropriate for this list. It is now in the realms of something > that would probably be better discussed with a good bottle of red or a > nice cold beer! > > There is lots that is 'broken' with the web and I suspect much of it we > will just have to live with and hope whatever the next evolution brings > us learns from our mistakes. > > Tim > > Garreau, Alexandre writes: > >> On 2018/10/27 at 07:15, Tim Cross wrote: >>> I have either misunderstood most of your position or I simply disagree >>> with it - I'm not sure which. >> >> maybe a mix of both? I hope it’s a misunderstandnment but if it’s not I >> want to understand too so to get to a constructive agreement. [...] Well for what it's worth I have enjoyed reading all this; especially Alexandre's exposition of the difference between italic and bold when being read 'from near' and 'from far'. Thanks both. Neil
[O] bibtex setup .dir-locals.el
Hello,
I would like to know how to set my ~References.bib~ as a dir-local
variable for use with bibtex (org-ref, reftex). I have this in my
~.dir-locals.el~. It keeps showing the global list of references.
Thanks!
#+BEGIN_SRC emacs-lisp
;;; Directory Local Variables
;;; For more information see (info "(emacs) Directory Variables")
(
(org-mode
(reftex-default-bibliography .
("/Class/Biomat/Hw/Project/References.bib"))
(org-ref-default-bibliography .
("/Class/Biomat/Hw/Project/References.bib"))
(bibtex-completion-bibliography .
("/Class/Biomat/Hw/Project/References.bib"))
(org-ref-bibliography-notes .
"/Class/Biomat/Hw/Project/report-biomat.org")
(bibtex-completion-notes-path .
"/Class/Biomat/Hw/Project/report-biomat.org")
(org-ref-pdf-directory . "/Class/Biomat/Hw/Project/Media/")
(bibtex-completion-library-path . "/Class/Biomat/Hw/Project/Media/")
)
(bibtex-mode
(reftex-default-bibliography .
("/Class/Biomat/Hw/Project/References.bib"))
(org-ref-default-bibliography .
("/Class/Biomat/Hw/Project/References.bib"))
(bibtex-completion-bibliography .
("/Class/Biomat/Hw/Project/References.bib"))
(org-ref-bibliography-notes
.
"/Class/Biomat/Hw/Project/report-biomat.org")
(bibtex-completion-notes-path
.
"/Class/Biomat/Hw/Project/report-biomat.org")
(org-ref-pdf-directory
.
"/Class/Biomat/Hw/Project/Media/")
(bibtex-completion-library-path
.
"/Class/Biomat/Hw/Project/Media/")
)
)
#+END_SRC
As an example:
#+BEGIN_EXAMPLE
reftex-default-bibliography is a variable defined in ‘reftex-vars.el’.
Its value is
("/Class/Biomat/Hw/Project/References.bib")
Original value was nil
Local in buffer report-biomat.org; global value is
("//Research/References.bib")
This variable’s value is directory-local, set by the file
‘/Class/Biomat/Hw/Project/.dir-locals.el’.
Documentation:
List of BibTeX database files which should be used if none are
specified.
When ‘reftex-citation’ is called from a document which has neither a
‘\bibliography{..}’ statement nor a ‘thebibliography’ environment,
RefTeX will scan these files instead. Intended for using
‘reftex-citation’
in non-LaTeX files. The files will be searched along the BIBINPUTS or
TEXBIB
path.
You can customize this variable.
#+END_EXAMPLE
My system
#+BEGIN_SRC emacs-lisp
(concat
(emacs-version) "\n"
(org-version) "\n"
(org-ref-version))
#+END_SRC
#+RESULTS:
: GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
: of 2018-07-05
: 9.1.14
: org-ref: Version 1.1.1
-
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: [O] *markup*, /markup/ and _markup_ true semantics
On 2018/10/29 at 08:19, Tim Cross wrote: > On reading your response, we are probably not as far apart as I first > thought. However, we have now wondered into discussion which probably > isn't appropriate for this list. It is now in the realms of something > that would probably be better discussed with a good bottle of red or a > nice cold beer! I don’t drink alcohol x) but I pretty much got the idea yeah ^^ > There is lots that is 'broken' with the web and I suspect much of it we > will just have to live with and hope whatever the next evolution brings > us learns from our mistakes. Indeed. But just waiting “whatever next evolution”, is not the good attitude I believe. Lisp and Emacs are great grounds for experimentation and improvement I believe too. What interest me is exiting as much as possible from the web, while trying to stay somewhat compatible with the good things, but even more with older and better things (RFC822, nntp, dsssl, semiology studies, true logical programming, etc.). I recall the time I was full of energy and constantly changing whatever was producing or containing html to make it more semantic, one day I should find again the energy to do that for multiple org backends, and, related to non-semantical org-backends, try to unify that to if not some stylesheet system, customizations used by elisp web browsers such as w3 or eww.
