From: Felix Dietrich <felix.dietrich@sperrhaken.name>
To: Samuel Wales <samologist@gmail.com>
Cc: help-gnu-emacs@gnu.org
Subject: Re: buffer substring of only visible text
Date: Wed, 28 Sep 2022 19:59:46 +0200 [thread overview]
Message-ID: <8735cb2xd9.fsf@sperrhaken.name> (raw)
In-Reply-To: <CAJcAo8sY_uSFEPxd_Ue-Zhb4qpf5uejFccQd0GGyEAAF_V3pGw@mail.gmail.com> (Samuel Wales's message of "Wed, 21 Sep 2022 15:57:57 -0700")
[-- Attachment #1: Type: text/plain, Size: 2329 bytes --]
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 #2: Commands to display text properties in a buffer --]
[-- Type: application/emacs-lisp, Size: 10727 bytes --]
[-- Attachment #3: Type: text/plain, Size: 1672 bytes --]
> 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
next prev parent reply other threads:[~2022-09-28 17:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-21 1:08 buffer substring of only visible text Samuel Wales
2022-09-21 1:34 ` Emanuel Berg
2022-09-21 11:34 ` Felix Dietrich
2022-09-21 22:57 ` Samuel Wales
2022-09-28 17:59 ` Felix Dietrich [this message]
2022-09-22 9:14 ` Michael Heerdegen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8735cb2xd9.fsf@sperrhaken.name \
--to=felix.dietrich@sperrhaken.name \
--cc=help-gnu-emacs@gnu.org \
--cc=samologist@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).