Re: Find first line FOLLOWING a sequence of matches

[Bob Proulx]

Subhan Michael Tindall wrote:
> I need to futz with it some more, hopefully tomorrow.
> But, one issue that I'm having is that using C-w to yank word at
> point doesn't cross punctuation, so I can't use c-w to grab the word

Is it really C-w kill-region not yank word?  The description confuses
me a little so not really sure exactly what you need there.

The suggestions about changing the syntax table to include punctuation
in words seems like a good possibility.  Especially if trying to M-@
mark-word or M-d kill-word which operate on words.  The disadvantage
is that one may like the previous definition for other things.

I also like the emacs-lisp snippet since I think this might be an
operation you will be doing periodically?  If so then writing a small
program in elisp to do the task will pay back rewards many times in
the future.  Especially when things become more complicated having a
real program can be better than brute forcing through with the keyboard.

But let me say a few words about emacs and creating a keyboard macro.
It can do what you want.  This is how I would do it.  Everyone will
edit the file differently.  This is simply one example way.

I would always search for the field separators.  I would move the
point to the next separator either forward or backward.  That will
leave the mark behind at the previous point location.  When editing I
would then use C-x C-x to exchange-point-and-mark to show the region
between.  (I eschew transient-mark-mode but I assume all new users are
using it.  In which case the region will be highlighted.)  Once the
region has been established then I would M-w kill-ring-save will copy
it to the kill ring.  (Or alternatively simply kill and yank to the
same effect with C-w C-y (kill-region, yank) which is the same on a
modified buffer.)  M-w copies the region to the kill ring.

By searching for the field separator it avoids differences in the
field holding one word or two words or zero or more.

You had previously said:
  Table like this: (abbreviated)
  |a|b|c|
  |a|d|e|
  |a|z||
  |m|b|c|
  |m|c|d|
  |ab|c|d|

  I'm looking  to write a macro to convert this table (on an
  occasionally recurring basis)
  To something like:
  ,* a
  |a|b|c|
  |a|d|e|
  |a|z||
  ,* m
  |m|b|c|
  |m|c|d|
  ,* ab
  |ab|c|d|

Can do.  Grab the first field to use for the new header.

  C-f C-s | C-b M-w

The first field is now in the kill ring.  Build your header using it.

  C-a C-o ,* C-y C-f

I am going to search for it using regular expressions C-u C-r.  I need
it for the '^' to anchor to the start of the line and not at other
field locations.  C-r is a non-RE search.  C-u C-r is an RE search.

  M->
  C-u C-r ^| C-y |
  C-a C-n

Jump to the bottom of the file and search upward using a regular
expression search.  Anchor to the start of the line.  Look for the
separator.  Yank in the saved pattern.  Separator.  That leaves you
just to the right of the first field.  The point will be sitting at
the first position of the second field.

Then C-a move-beginning-of-line.  Then C-n for next line.  Maybe at
that point you will be on the next line.  Maybe.  Maybe not.  It
depends.  Grr...  Another peeve of mine.

This is tricky due to the new emacs default of visual line mode.  Up
until recently next-line always took you to the next line.  But in
recent emacs the default is now visual line mode.  I eschew
line-move-visual for exactly the reason that next-line no longer takes
you to the next line.  Now with line-move-visual set it depends upon
line length and window length.  (The end condition also depends upon
the value of next-line-add-newlines too.)  If you have the new default
value and the line is longer than your display and wraps then C-n
won't put the point on the next line.  It will put it somewhere in the
wrapped area.  I can only suggest (setq line-move-visual nil) to
return to a sane state.  Others obviously disagree with me.  I can
only note it here and you must deal with the behavior there.

Having the point now on the next line where you want to start a new
header.  Terminate the macro.  Call the macro.  It should repeat.

That should have you with a manual way to macro out an edit to add
those headers to the table that you wanted to add.  It does not depend
upon changing the word character syntax table.

> at point into the search buffer (which would be quick & easy.
> IE zipc^odes_hold
>             Pt here
>       C-w pulls zipcodes, not zipcodes_hold
> If there's a way I can define words to only be bounded by whitespace
> I should be able to whip up a keyboard macro for the rest I
> believe.

Changing the word characters will work too.  There is more than one
way to do it.  I prefer to search for the separator instead of
counting on there being a certain type of field.  Different
(key)strokes for different folks.

Bob