help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: buffer substring of only visible text


From: Felix Dietrich
Subject: Re: buffer substring of only visible text
Date: Wed, 28 Sep 2022 19:59:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux)

Hello Samuel,

Samuel Wales <samologist@gmail.com> writes:

> thank you for your response.  very interesting and thorough.
>
> this problem with or without manuals has made my head swim ever since
> text properties arrived.  i'm sure the manuals are good but my broken
> brain is not really getting text properties.  results are sometimes
> off, i don't know the special ones, etc.

If you have a concrete problem, some small snippet you were
experimenting with and that does not do what you were expecting then,
maybe, someone on the list could help you with understanding it.  Just
play around with some code, compare the actual results with your
expectations, and try to figure out your misapprehensions either
yourself or by asking others.  This way, after some time and
frustration, things will hopefully become clearer and you develop an
intuition for Emacsʼ idiosyncrasies.

> i forgot to mention more explicitly that i was hoping to not depend on
> htmlize as it is not in core, but that's a side point, as i will use
> htmlize if necessary, and also i think now, maybe, it /might/ be
> better to go line by line?  but i am not sure.

The little snippet only uses a few utility functions that you could
easily copy and paste from htmlize and give your own prefix.

> for me it would be better if thre were a tool more powerful than c-u
> c-x = to inspect them.  for example, if there were a tool to show all
> text properties and their intervals in a region or buffer or string.
> and also links to where any special text properties are documented.
> but that's a wish list i guess.  it would help me understand emacs
> anyway.

I dabbled around a little with your idea and came up with two commands.
They do not do exactly what you want, have issues (only some of them I
am vaguely aware of) and might be at least a little broken
(‘hl-line-mode’ for example leaves partially highlighted lines around),
but you might still find them interesting as toys to play around with.
In any case, I had fun and learned a little about Emacs and its Lisp.
One shows in another buffer the active properties at point; the buffer
is updated when point is moved, the other shows active properties within
a region.  Properties in overlapping overlays with lower priority are
not shown.

Attachment: property-browser.el
Description: Commands to display text properties in a buffer


> more of the x for which this is possibly an xy problem: as noted, i am
> trying to copy visible text from buffer a to b.  and i want buffer b
> to have text properties that include markers to jump to a for specific
> lines.  kinda like magit jumps to files.

I donʼt know how magit does it.  Maybe it uses the line information
provided in the diff hunks?  You could read itʼs source.

> and so, those text properties in buffer b would include, in b, the
> markers in a.  or... something.   you can probably tell i am a little
> lost here.  but with such a funciton like yours, i would put the
> markers in a, put the text properties redundantly in a, then copy over
> using the function.  the redundant text properties seems wrong
> however.  it seems efficient.

What is in those text properties that creates the need to copy and
duplicate them?

> so idk.  one alternative seems to be to go line by line through a,
> insert markers in a, then create a string for each line with a text
> property containing the marker, then insert that string into b, then
> continue with the next matching visible line in a.
>
> which seems inefficient.  idk if this is a common problem: copy parts
> of buffer a to buffer b such that you can RET to get to a.

I donʼt know either.  If no one else chimes in and your search engine
does not provide you with an answer, just start writing some code and
playing around with your ideas to develop a better understanding of the
problem and possible solutions.  Donʼt start worrying to much about
efficiency at the beginning unless your Emacs or your Computer grind to
a halt.

-- 
Felix Dietrich

reply via email to

[Prev in Thread] Current Thread [Next in Thread]