Re: Font width in Properties Drawer
Garrett Rolfs writes: > Executing C-u C-x = on a space in this area indicates there is no face > defined. So I suspect the answer is currently no. I don’t know if this is useful feedback, but I’m running Org-mode version 9.3.7 and in my properties drawers, the keywords are in org-special-keyword face and the values are in org-property-value face. Be seeing you, norm -- Norman Tovey-Walsh https://nwalsh.com/ > Lawyers, I suppose, were children once.--Charles Lamb signature.asc Description: PGP signature
Re: Anyone doing any fancy customizations of source blocks?
Joost Kremers writes: > In Emacs 27, add an `:extend t` property to the face. Thank you! I somehow failed to connect that with my move to Emacs 27 a while back. Be seeing you, norm -- Norman Tovey-Walsh https://nwalsh.com/ > Sometimes in life situations develop that only the half-crazy can get > out of.--La Rochefoucauld signature.asc Description: PGP signature
Re: Anyone doing any fancy customizations of source blocks?
> On 3 June 2020, Diego Zamboni wrote:
>> I use the config John mentioned and I like it - though I use different
>> symbols. Here's my config if you want an example:
>> https://github.com/zzamboni/dot-emacs/blob/master/init.org#source-code-blocks
This example reminded me of something that’s been puzzling me. In the
screenshot, the background color of lines that begin and end a source
block extend all the way across the screen.
When I change the faces for org block begin/end to something with a
background color, the color only extends to the end of the characters on
that line. The same is true if I change the background color of the
content of the block.
This is quite distracting. I thought “this must be the consequence of
some other mode I’m using or something” and I decided to test that. I
fired up “emacs -q” and loaded the code pointed to by the post above.
What I get is:
What’s the trick to get the background color to extend across the entire line?
<
Be seeing you,
norm
--
Norman Tovey-Walsh
https://nwalsh.com/
> ...it is significant that we are called the 'information society'—not
> the thinking society, not the deliberative society, not the society of
> reason and rationality.--Lloyd Morrisett
signature.asc
Description: PGP signature
Re: Faces and spaces
> I pushed a fix on master for that. Please give it a try if you can. Works perfectly, thank you! Be seeing you, norm -- Norman Tovey-Walsh https://nwalsh.com/ > Time is that quality of nature which keeps events from happening all at > once. Lately it doesn't seem to be working. signature.asc Description: PGP signature
Faces and spaces
Hello,
I admit, up front, that this is of no practical consequence, but it’s
something that distracts me every single time I see it. (Which, I might
argue, is a practical consequence *for me*.)
Consider the following todo:
** TODO Do something next week.
DEADLINE: <2020-04-28 Tue>
:PROPERTIES:
:CREATED: [2020-04-21 Tue 08:17]
:END:
This is the thing to do.
DEADLINE: and :CREATED: are in the org-special-keyword face.
:PROPERTIES: and :END: are in the org-drawer face.
Both of those faces are monospace and I would prefer them to remain that
way.
The prose of my entry is fontified but not in any special face. I’m
using the Poet theme so that means it’s in some proportional face.
Here’s the source of my irritation: the spaces preceding “DEADLINE” and
“:CREATED:” are, like the prose, simply fontified. The spaces preceding
“:PROPERTIES:” and “:END:” are in the org-drawer face.
What this means is that the entry appears like this:
** TODO Do something next week.
DEADLINE: <2020-04-28 Tue>
:PROPERTIES:
:CREATED: [2020-04-21 Tue 08:17]
:END:
This is the thing to do.
Is there any way to get the spaces preceding both sets of lines in the
same face? I don’t much care which, I’d just prefer if they were
aligned. Even getting just :CREATED: aligned would be an improvement.
I think they’d align if I put the monospace ones in the proportional
font, so I guess that’s an option, but I’d prefer to have them
monospace.
Be seeing you,
norm
--
Norman Tovey-Walsh
https://nwalsh.com/
> Hanging is too good for a man who makes puns; he should be drawn and
> quoted.--Fred Allen
signature.asc
Description: PGP signature
Re: Survey: changing a few default settings for Org 9.4
Mark E. Shoulson writes:
> On 2/19/20 2:39 AM, Bastien wrote:
>> - org-hide-emphasis-markers => t
>
> Just to note: I've been working on a minor-mode in which the emphasis
> markers are "invisible" but not hidden (i.e. they still take up space,
[…]
> size, so the extra space is not quite as obvious. Does this sound
> interesting to anyone? Right now the code is kind of a mess, but it
> could be refined.
Sounds interesting to me.
Be seeing you,
norm
--
Norman Tovey-Walsh
https://nwalsh.com/
> Why is there always money for war and not for education?
signature.asc
Description: PGP signature
Re: org-babel-load-file support elisp
>> The problem now is that removing support for 'elisp' would break too >> much. > > What I suggest for this particular issue is this: first be liberal > while staying consistent (thus allowing "elisp" as Troy suggest), > then be strict when a major release is issued (thus removing aliases > that are problematic, not just "elisp" but others.) > > WDYT? Troy, would you be able to prepare a patch for this? My 2¢ from the peanut gallery. Generally speaking, I’m in favor of consistency. A couple of months ago, I stumbled over the fact that ‘elisp’ seemed to do syntax highlighting correctly but didn’t tangle. I didn’t, at the time, work out the cause of the problem, I just learned to use ‘emacs-lisp’ as the language name. Looking at this thread, it seems like there are a bunch of exceptions to the rule that the language is be the name of the mode without ‘-mode’. Just off the top of my head, I can think of several languages supported by multiple modes. If the rule is that the language is the mode name, then if I use ‘extra-special-language-mode’ to edit ‘language’, do I have to use ‘extra-special-language’ as the language name? Is that going to seem natural? What burden does that put on the developer of ‘extra-special-language-mode’ to make tangle and other Org-mode features work like they would for ‘language-mode’? I wonder if it makes more sense to invent a mechanism for assigning language synonyms that can be used throughout Org? Be seeing you, norm P.S. Just to prove I can play devil’s advocate, I’m very conscious of the fact that a few days ago, I invented an ‘xproc-mode’ as a vacuous extension to ‘xml-mode’ precisely *because* I wanted to define different org-babel-execute behavior. -- Norman Tovey-Walsh | Some disguised deceits https://nwalsh.com/ | counterfeit truth so perfectly | that not to be taken in by them | would be an error of | judgment.--La Rochefoucauld signature.asc Description: PGP signature
Re: equal syntax highlighting for publishing code blocks to html and pdf
Bastien writes: >> Frequently I publish org-mode documents containing source code blocks >> to html (htmlize) and pdf (minted). I would like to see the same >> colors in both export types. But >> I cannot figure out, what’s the best way to achieve this. >> >> Has anyone solved this problem? Are there any hints? On casual inspection, HTML export seems to derive the colors from the way Emacs has fontified the buffer. It appears to insert the colors literally, which I guess it has to if it’s going to base them on face properties. > If you find a solution, please mention it here, others may be > interested. I think there are two plausible ways forward. If you like the colors used by minted, you can try changing the faces in Emacs to match them. If you like the colors used by Emacs, you can change the colors used by minted to match. Minted appears to use pygments, so you could create your own style[1] and then use that style in your documents[2]. My own approach to printed output[3] doesn’t use minted yet, so I haven’t actually tried to do any of these things :-) Be seeing you, norm [1] https://pygments.org/docs/styles/ [2] https://tex.stackexchange.com/questions/218556/style-pygments-at-pythontex [3] https://so.nwalsh.com/2020/01/05-latex -- Norman Tovey-Walsh | The fact that an opinion has been https://nwalsh.com/ | widely held is no evidence | whatever that it is not utterly | absurd; indeed in view of the | silliness of the majority of | mankind, a widespread belief is | more likely to be foolish than | sensible.--Bertrand Russell signature.asc Description: PGP signature
