Re: can emphasis emphasize this?

2023-11-12 Thread Samuel Wales
haha ah the old zws thing.  of course.

hadn't crossed my mind!  this isn't for export [yet] and previously
discussed soluytions for using syntax made me think of exports so it
slipped my mind.  i do find it odd that a non-visible character is
needed, but thanks for bringing it up and providing the code.

on the basis of the invisibilty thing, i /might/ stick to using spc
when emphasis is first char of a = note, if no more responses, but
will consider it!


On 11/12/23, Marcin Borkowski  wrote:
>
> On 2023-11-13, at 05:29, Samuel Wales  wrote:
>
>> if it is as above, the emphasis does not show.  but if i put a space
>> after =, it does show.  i kind of want to keep trying without space,
>> but i want emphasis.
>>
>> is this a possible hack to emphasis syntax?  we've changed that around
>> a bunch i know, and forgotten details.  i suspect it is at your own
>> risk stuff now.
>
> My go-to solution is this:
>
> (defun insert-zero-width-space ()
>   "Insert Unicode character \"zero-width space\"."
>   (interactive)
>   (insert 8203))
>
> Hth,
>
> --
> Marcin Borkowski
> http://mbork.pl
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com



Re: can emphasis emphasize this?

2023-11-12 Thread Marcin Borkowski


On 2023-11-13, at 05:29, Samuel Wales  wrote:

> if it is as above, the emphasis does not show.  but if i put a space
> after =, it does show.  i kind of want to keep trying without space,
> but i want emphasis.
>
> is this a possible hack to emphasis syntax?  we've changed that around
> a bunch i know, and forgotten details.  i suspect it is at your own
> risk stuff now.

My go-to solution is this:

(defun insert-zero-width-space ()
  "Insert Unicode character \"zero-width space\"."
  (interactive)
  (insert 8203))

Hth,

-- 
Marcin Borkowski
http://mbork.pl



can emphasis emphasize this?

2023-11-12 Thread Samuel Wales
tldr can i emphasize
=/emphasized/ not emphazised
or find a workaround that is easy to type?


i like to notate meta-notes with = like this:

=/send to mary ka/
a bunch of stuff

or

=i am skeptiucal this is true
he said aliens invadded yesterday

or even just notes by themselves with blank space after in org body
text to describe the entry in meta terms.  such as links to other
stuff etc.  and tses.

i do this in text notes to myself all over emacs but especially in org
body text.

[i don't do anything programmatic with them; they are just notes to
myself.  but programmatic expansion of hte idea into features would b
interesting.]

i just have a small question of syntax and workarounds.

if it is as above, the emphasis does not show.  but if i put a space
after =, it does show.  i kind of want to keep trying without space,
but i want emphasis.

is this a possible hack to emphasis syntax?  we've changed that around
a bunch i know, and forgotten details.  i suspect it is at your own
risk stuff now.

if that's not a good option, are there other options like macros,
except as easy to type just like the =?  thanks.

-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com



org-src-font-lock-fontify-block is unaware of org-edit-src-content-indentation, leading to fontification issues

2023-11-12 Thread JD Smith
When `org-edit-src-content-indentation’ is non-nil (default: 2), editing SRC 
blocks preserves this amount of extra indentation space at the beginning of 
each line of the block, removing and then re-adding it on round trips through 
`org-edit-src-code’.

But `org-src-font-lock-fontify-block' does not consider this extra space. 
Instead it simply copies the full block verbatim into e.g.  
*org-src-fontification:python-mode*, as if the extra indent space were a 
legitimate part of the source.  Normally this wouldn’t be a problem, as faces 
are attached to keywords.  But for any fontification that depends explicitly on 
indentation, this leads to incorrect results.  For example, my indent-bars 
package adds indentation bars via text properties based on absolute column 
position.  These bars are then offset in the displayed org src block by 2 
columns from their correct locations, due to the extra space org has put there.

A sensible solution might be for fontify-block to strip 
`org-edit-src-content-indentation’ worth of space from the beginning of each 
line, just as is done for src block editing, then perform the fontification, 
then add that space back to the fontified text for display.

Thanks for all your work on org.

Re: [BUG] org-edit-special is not working with korean characters [9.6.6 (release_9.6.6 @ /home/sukbeom/opt/share/emacs/29.1/lisp/org/)]

2023-11-12 Thread Ihor Radchenko
sukbeom@gmail.com writes:

> I found that there is a bug with typing Korean characters with table.el
> table.
> ...
> The thing is, whenever I type korean characters within the table.el
> table, it just inserts characters, breaking the table.
>
> +--+--+---+
> |First row |Japanese  |Korean |
> +--+--+---+
> |Test #1   |あえいおう|아에   | <- expected
> +--+--+---+
> |Test #1   |あえいおう|아에   | <- actual behavior
> +--+--+---+

org-edit-special uses table.el facilities to edit the table.
If there are any problems with table.el, please report them to Emacs devs
- table.el is not a part of Org mode; we just provide a limited support
for table.el tables.

Not an Org mode bug.
Canceled.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at