Maybe add interactions between meow-*-expand and beacon

[Haxxflaxx]

I've had this thought floating around for a while that if we had some way to manipulate the beacons and their selections, maybe we could lessen the need to record as many macros while doing edits in structured text.

I don't really know how feasible this is to do, or if it is as useful as it seems in my head.

The idea is that we have commands that place beacons and commands that manipulate the selections of those beacons. This would allow us to do something like "t = ] l" to place a beacon at each equal sign, then make a selection from each beacon to the end of the line.

There are probably a bunch of edge cases that I'm not thinking of, but I think this could be good to prototype.

[DogLooksGood]

I think this is a good idea, and I had thought about it. I want to make the selection behaviors as close to the behaviors in normal state as possible. I'll probably find a time to work on it. I'm missing some motivation because I believe these use cases are too few.

[Haxxflaxx]

Having selections behave closer to how it is in normal mode might lead to more of an expected behavior. Maybe having some prefix for placing the cursors? It's hard to say what would work well without actually trying it.

I agree that the use cases may be few. In most cases I either use it as a simple way of running macros on a region, or I place cursors by regex. A lot of things I use beacons for could probably be solved as well or better with a regex replace.

[Haxxflaxx]

This may be outside the scope of what meow beacons are, or should be, but bare with me. I've been thinking about what beacon could be, what would be an "intuitive" interface, and what incoming users would expect it to be.

The first thing that seem to happen when new users come in contact with the beacon state is that they compare it to multiple-cursors, then get confused when it doesn't work the same way. Naturally this is the case because the meow beacon state is quite a different thing, but in many ways, I don't think it needs to be.

@DogLooksGood mentioned making the selection behaviors closer to how things work in normal mode. I think this is a great idea as it would allow a smoother transition between normal editing and multi-editing.

An extension of this would be to separate out placing cursors from the normal motion and editing functionality. Maybe a transient prefix could be used for beacon manipulation functions, like placing or removing beacons, maybe some stepping function for stepping through the beacons allowing for viewing them if they are outside the window.

This would allow normal mode to function like you would expect, but every action is also run on all the beacons. I think this would make it easier to understand as it would do the same as normal, only everywhere.

I have glazed over a lot of implementation related details here, partly because I don't think I'm good enough at hacking elisp yet to gauge how difficult this would be to implement. But I can see some areas that might need some careful thought.

First is that of performance. On a large region, say a full source file, with a large amount of beacons; how would cycling through and repeating every key-press in a macro impact the editing experience? This probably needs to be tested to be sure, but we already have an escape hatch if recording macros works the same as today. Then the edits would be batched and executed with less overhead.

Then there is overlapping beacons. This is a problem with my first proposal as well and would need to be dealt with if any form of extending selections could be done in beacon mode. We would need to go through the beacons and merge the selections so that we get a single beacon for that area. Either that or have the beacons block each other so that they end up next to but not overlapping.

There are probably a lot of edge cases that I've missed. Sorry for the long winded post, I've been looking a bit at how helix handles multi-editing and while it is in many ways quite a different thing, I think there are interesting ideas to borrow from it.

[DogLooksGood]

Well, maybe we have a little misunderstanding here. I know how kakoune and helix handle the multi-selection but that's not something I want in Emacs. Obviously one reason is about performance, but it's not the only reason.

In normal mode, I want a way to locate every meaningful position around current cursor in just one move(or with some extra expands). Bring this idea to beacon state, I want to be able to create beacons in every meaningful patterns in one move(or with some extra expands). It is not about have another key layer for moving the beacons.

Movement in Normal State	Patterns in Beacon State
col (left/right)	every col
lines with expanding	every N line
mark word(for search)	every same word
next/prev-word	every begin/end of word
join(indentation)	every indentation
find/till CHAR	every CHAR
block	undefined

The problem is how many patterns we should support and how to support them in an unified way.

1. I don't think we need to support beacons in a list of arbitrary positions, as we are using keyboard macros. Instead of find & set-beacon, we do find & call-macro.
2. I don't think we need a extra layer to manipulate beacons, we should still focus on patterns. For example, we don't support sentences and paragraphs yet, as there's no such motion commands in Meow. Maybe we should add them.

BTW, there are some packages have similar features. They cover more use cases than Meow.
markmacro
macrursors

[Haxxflaxx]

When you previously referred to making beacon mode closer to how normal mode function, is it in terms of selections?
That is if I call next-word where now a beacon is placed at the end of each word, it would instead select each word? Similar to what happens with line selection?

I think the problem I'm having is that I don't have a good grasp of what problems beacon state is supposed to solve, and when I instead should reach for some other tool.
For very simple cases beacons are great, but I feel that I quickly run into cases where editing structured text becomes tedious.

I've created some convenience functions for lowering the friction, but in the end maybe it's more of a job for fancy regex replace.

[DogLooksGood]

Can you give an example (or maybe some) where the beacon state doesn't work well?

[Haxxflaxx]

I don't have that many in store. A recent one that I ran into was extracting connection info out to a json object.
So turning:

  snowflake_conn = snowflake.connector.connect(
      account="snowflake_acount",
      user="snowflake_user",
      private_key_file="path/to/key_file",
      private_key_file_pwd="key_password",
      role="snowflake_role",
      database="snowflake_database",
      warehouse="snowflake_warehouse",
      schema="snowflake_schema",
  )

Into this:

  "snowflake":{
    "account":"snowflake_acount",
    "user":"snowflake_user",
    "private_key_file":"path/to/key_file",
    "private_key_file_pwd":"key_password",
    "role":"snowflake_role",
    "database":"snowflake_database",
    "warehouse":"snowflake_warehouse",
    "schema":"snowflake_schema"
  },

and this:

  snowflake_conn = snowflake.connector.connect(
      account=config["snowflake"]["account"],
      user=config["snowflake"]["user"],
      private_key_file=config["snowflake"]["private_key_file"],
      private_key_file_pwd=config["snowflake"]["private_key_file_pwd"],
      role=config["snowflake"]["role"],
      database=config["snowflake"]["database"],
      warehouse=config["snowflake"]["warehouse"],
      schema=config["snowflake"]["schema"],
  )

If I remember correctly I did a lot of it by recording macros and executing them on beacons per line. The biggest problem I faced was was that I sometimes moved by word instead of symbol which broke when it applied to the other lines.

That and that I was weirdly confused about the record- and the end- macro buttons. The last thing I solved for myself by just making a dwim macro button that does both based on context for me.

I've also thought that it would be nice to have meow-join actually mark the area, that way it would be easy to just do: join, delete; to collapse a list into a single line.

Sometimes I also use beacon mode for renaming things, but I'm not sure it is the best for it. I made a grab-word and grab-symbol function that calls meow-bounds-of-thing to get a region, grabs the region then marks the corresponding thing. I haven't played with it enough to figure out if it's a good idea or not yet.

[DogLooksGood]

I think you don't need much fancy features to achieve this. Create a beacon, on each line, start recording, then find position with find = or till =, and it should work. But probably we need a way to call macro by their name, or hook any commands those calls a macro for batched execution.

Of course, you can have a lot commands, but why we want fewer commands is because we only have limited key space. Considering how many keys we press for doing one job. If we have one command on f and another one on h, and now we combine them into one, let's say we bound it to F. In fact, it changed nothing, F is two keys, Shift + f. And it requires an accuracy on the release timing of Shift. There's no advantage over fh.

[Haxxflaxx]

Makes sense. I noticed that the bounds-of-thing into grab without moving point can be done by poping the mark ring, so those functions aren't as useful as I thought when writing them.

One thing that I don't know how to do, and this may not really be a beacon thing is to append a block of lines onto a different block of lines. That is:

Line1
Different_line2
Also_line3
Such_line4

LineA
LineB
LineC
LineD

==into==>

Line1: LineA
Different_line2: LineB
Also_line3: LineC
Such_line4: LineD

The only half-way decent way I can think of is to use a rectangle, but that leaves a lot of whitespace cleanup, especially if the other block also is different lengths.

[DogLooksGood]

This way?

Screencast_20241205_024504.webm

If they don't follow a pattern, we can't use beacon state. We can do it with kmacro and secondary selection swap. You can do swap cursor and an empty secondary selection, it allows to jump back and forth.

Screencast_20241205_025206.webm

The second example might not seems to be useful, but sometimes I have a very long buffer and have to do type a lot between each copy.

[Haxxflaxx]

Now that first one is pretty much exactly what I was looking for. It didn't even occur to me that the macro recorded inside of the secondary selection also can act outside of it.

I do use swap-grab a lot for moving things around. It's really nice. I keep forgetting though that popping it will return to where it was placed.