A feature to go to last edit locations

A feature to go to last edit locations

[Daniel Martín]

Some IDEs and text editors provide a feature to go to the position of
the last edit location across all buffers.  For example, in Eclipse or
IntelliJ IDEA, this feature is under Navigate, Last Edit Location.  In
Vim, this feature is called a "change list jump" [1], but it seems to
work in a per-buffer basis.

The closest thing in Emacs is pop-global-mark, but it's not quite the
same feature. The global mark ring requires that the user sets the mark
in advance, and most editing commands do not set the mark.  Information
about last edit locations is already kept in buffer-undo-list, but this
list is per-buffer and does not contain timestamps, so generating a
"global" list for all buffers out of this data structure does not seem
very possible or efficient at the moment; it may need a new data
structure, perhaps at the C level.

My question is: Is there any interest on this new feature?  If so, I
have some questions about how it may fit in Emacs:

- When popping entries from this new "last edit locations ring", should
  we give users the option to skip some changes?  For example, to not go
  to changes in the minibuffer (which will probably be inactive), or to
  other kinds of buffers.

- Should this feature restore killed buffers from files, if possible?
  pop-global-mark does not do that, but the Last Edit Location feature
  in IDEs tries to do that, AFAIK.

- Should this feature be linked to undo information?  That is, if undo
  is disabled for a buffer, should the edit change locations in that
  buffer be preserved?

- I think there should be a configurable threshold to skip adding
  entries that are close to each other.  For instance, an editing
  session that goes like

     Hello, world! M-<backspace> World!

  would generate 3 last edit location entries which are probably
  uninteresting to users.  We should give them an option to skip
  recording some changes (perhaps those that are in the same line, or
  less than a number of character positions apart from another entry in
  the ring).

What do you think?  Third-party packages like goto-last-change.el [2] or
session.el [3] (see session-jump-to-last-change) implement this feature
in a per-buffer basis, but I wonder if we could do better and implement
something that works across buffers.

[1]: https://vimhelp.org/motion.txt.html#changelist
[2]: https://www.emacswiki.org/emacs/goto-last-change.el
[3]: https://www.emacswiki.org/emacs/session.el

Re: A feature to go to last edit locations

[Eli Zaretskii]

> From: Daniel Martín <mardani29@yahoo.es>
> Date: Sun, 12 Feb 2023 18:41:20 +0100
> 
> 
> Some IDEs and text editors provide a feature to go to the position of
> the last edit location across all buffers.  For example, in Eclipse or
> IntelliJ IDEA, this feature is under Navigate, Last Edit Location.  In
> Vim, this feature is called a "change list jump" [1], but it seems to
> work in a per-buffer basis.
> 
> The closest thing in Emacs is pop-global-mark, but it's not quite the
> same feature.

Emacs also has registers.

Re: A feature to go to last edit locations

[Daniel Martín]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Daniel Martín <mardani29@yahoo.es>
>> Date: Sun, 12 Feb 2023 18:41:20 +0100
>> 
>> 
>> Some IDEs and text editors provide a feature to go to the position of
>> the last edit location across all buffers.  For example, in Eclipse or
>> IntelliJ IDEA, this feature is under Navigate, Last Edit Location.  In
>> Vim, this feature is called a "change list jump" [1], but it seems to
>> work in a per-buffer basis.
>> 
>> The closest thing in Emacs is pop-global-mark, but it's not quite the
>> same feature.
>
> Emacs also has registers.

Yes, but registers still require that users explicitly save the position
in a register beforehand.  Users may be editing a file, then switch to
another file (or to another part of the same file) and then get a bit
lost and ask themselves "where is what I was editing before?".  If they
haven't saved their position in a register or in the mark ring, Emacs
can't help them.

Re: A feature to go to last edit locations

[Eli Zaretskii]

> From: Daniel Martín <mardani29@yahoo.es>
> Cc: emacs-devel@gnu.org
> Date: Sun, 12 Feb 2023 19:59:03 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Daniel Martín <mardani29@yahoo.es>
> >> Date: Sun, 12 Feb 2023 18:41:20 +0100
> >> 
> >> 
> >> Some IDEs and text editors provide a feature to go to the position of
> >> the last edit location across all buffers.  For example, in Eclipse or
> >> IntelliJ IDEA, this feature is under Navigate, Last Edit Location.  In
> >> Vim, this feature is called a "change list jump" [1], but it seems to
> >> work in a per-buffer basis.
> >> 
> >> The closest thing in Emacs is pop-global-mark, but it's not quite the
> >> same feature.
> >
> > Emacs also has registers.
> 
> Yes, but registers still require that users explicitly save the position
> in a register beforehand.  Users may be editing a file, then switch to
> another file (or to another part of the same file) and then get a bit
> lost and ask themselves "where is what I was editing before?".  If they
> haven't saved their position in a register or in the mark ring, Emacs
> can't help them.

Given how much one moves during editing, I have hard time imagining
how a command that returns me to "the last place I edited" could be
useful without me telling Emacs which of those places is important and
which isn't.  If you invent a mechanism to save "the last location"
automatically, you are going to add a facility that will have a high
probability of false positives.

In any case, whatever method of deducing automatically which place to
record, I think it's better to build the feature on top of registers,
since they are already equipped for saving and restoring locations.

Re: A feature to go to last edit locations

[andrés ramírez]

Hi. Guys.
>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:


[...]


    Eli> In any case, whatever method of deducing automatically which place to record, I think it's
    Eli> better to build the feature on top of registers, since they are already equipped for saving
    Eli> and restoring locations.

evil-mode has gi (go to the last inserting point and enters
insert-mode). I am a former evil-mode user. 

Could that implementation be ported to emacs?

Best Regards

Re: A feature to go to last edit locations

[Daniel Martín]

andrés ramírez <rrandresf@hotmail.com> writes:

> Hi. Guys.
>>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
>
>
> [...]
>
>
>     Eli> In any case, whatever method of deducing automatically which place to record, I think it's
>     Eli> better to build the feature on top of registers, since they are already equipped for saving
>     Eli> and restoring locations.
>
> evil-mode has gi (go to the last inserting point and enters
> insert-mode). I am a former evil-mode user. 
>
> Could that implementation be ported to emacs?
>

I see that Evil uses the NonGNU ELPA package goto-chg
(https://elpa.nongnu.org/nongnu/goto-chg.html) to implement that
functionality.

Re: A feature to go to last edit locations

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]


Daniel Martín <mardani29@yahoo.es> writes:

> andrés ramírez <rrandresf@hotmail.com> writes:
>
>> Hi. Guys.
>>>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
>>     Eli> In any case, whatever method of deducing automatically which place to record, I think it's
>>     Eli> better to build the feature on top of registers, since they are already equipped for saving
>>     Eli> and restoring locations.
>>
>> evil-mode has gi (go to the last inserting point and enters
>> insert-mode). I am a former evil-mode user. 
>>
>> Could that implementation be ported to emacs?
>
> I see that Evil uses the NonGNU ELPA package goto-chg
> (https://elpa.nongnu.org/nongnu/goto-chg.html) to implement that
> functionality.

I use that package outside Evil all the time. Any mode that clobbers the
shortcut I assigned to it (C-.) blocks my productivity a lot. That’s the
main reason why I don’t have flyspell active while writing emails.

It only works inside buffers, but with ido for changing buffers and
dumb-jump/xref support for jumping back after cross-file navigation, I
don’t need more. This jumping back after an explicit cross-file
navigation command is actually closer to what I need than what intellij
offers. I don’t want to go back to the buffer I selected via
switch-buffer, but if "find reference" takes me to another file, I need
a way to jump back.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: A feature to go to last edit locations

[Juri Linkov]

>> Daniel Martín <mardani29@yahoo.es> writes:
>> I see that Evil uses the NonGNU ELPA package goto-chg
>> (https://elpa.nongnu.org/nongnu/goto-chg.html) to implement that
>> functionality.
>
> I use that package outside Evil all the time. Any mode that clobbers the
> shortcut I assigned to it (C-.) blocks my productivity a lot. That’s the
> main reason why I don’t have flyspell active while writing emails.

You can unbind this key:

```
(with-eval-after-load 'flyspell
  (keymap-unset flyspell-mode-map "C-."))
```

> It only works inside buffers, but with ido for changing buffers and
> dumb-jump/xref support for jumping back after cross-file navigation, I
> don’t need more. This jumping back after an explicit cross-file
> navigation command is actually closer to what I need than what intellij
> offers. I don’t want to go back to the buffer I selected via
> switch-buffer, but if "find reference" takes me to another file, I need
> a way to jump back.

Something like this will get the most recently used buffer with undo,
then the logic from goto-chg can navigate to the last undo entry:

```
(seq-sort (lambda (b1 b2)
            (time-less-p
             (with-current-buffer b2 buffer-display-time)
             (with-current-buffer b1 buffer-display-time)))
          (seq-remove (lambda (b)
                        (with-current-buffer b
                          (or (not buffer-undo-list)
                              (eq buffer-undo-list t)
                              buffer-read-only
                              (not buffer-display-time)
                              (string-match-p "\\` " (buffer-name b)))))
                      (buffer-list)))
```

RE: [External] : Re: A feature to go to last edit locations

[Drew Adams]

> > >> Some IDEs and text editors provide a feature to go to the position
> of
> > >> the last edit location across all buffers.  For example, in Eclipse
> or
> > >> IntelliJ IDEA, this feature is under Navigate, Last Edit Location.
> In
> > >> Vim, this feature is called a "change list jump" [1], but it seems
> to
> > >> work in a per-buffer basis.
> > >>
> > >> The closest thing in Emacs is pop-global-mark, but it's not quite
> the
> > >> same feature.
> > >
> > > Emacs also has registers.
> >
> > Yes, but registers still require that users explicitly save the
> position
> > in a register beforehand.  Users may be editing a file, then switch to
> > another file (or to another part of the same file) and then get a bit
> > lost and ask themselves "where is what I was editing before?".  If
> they
> > haven't saved their position in a register or in the mark ring, Emacs
> > can't help them.
> 
> Given how much one moves during editing, I have hard time imagining
> how a command that returns me to "the last place I edited" could be
> useful without me telling Emacs which of those places is important and
> which isn't.  If you invent a mechanism to save "the last location"
> automatically, you are going to add a facility that will have a high
> probability of false positives.
> 
> In any case, whatever method of deducing automatically which place to
> record, I think it's better to build the feature on top of registers,
> since they are already equipped for saving and restoring locations.

FWIW, Bookmark+ has `bmkp-automatic-bookmark-mode', which
just records locations with a timer delay.

Not claiming it's what's requested here, but it might be
similar or serve as food for thought.

  When the mode is enabled in the current buffer, a bookmark is
  automatically set every `bmkp-automatic-bookmark-mode-delay' seconds,
  using the setting function that is the value of option
  `bmkp-automatic-bookmark-set-function'.  Note that a buffer must be
  current (selected) for an automatic bookmark to be created there - it
  is not enough that the mode be enabled in the buffer.

  Turning the mode on and off runs hooks
  `bmkp-automatic-bookmark-mode-on-hook' and
  `bmkp-automatic-bookmark-mode-off-hook', respectively.

  If you want the automatic bookmarks to be temporary (not saved to your
  bookmark file), then customize option
  `bmkp-autotemp-bookmark-predicates' so that it includes the kind of
  bookmarks that are set by `bmkp-automatic-bookmark-set-function'.
  For example, if automatic bookmarking sets autonamed bookmarks, then
  `bmkp-autotemp-bookmark-predicates' should include
  `bmkp-autonamed-bookmark-p' or
  `bmkp-autonamed-this-buffer-bookmark-p'.

  If you want the automatically created bookmarks to be highlighted,
  then customize option `bmkp-auto-light-when-set' to highlight
  bookmarks of the appropriate kind.  For example, to highlight
  autonamed bookmarks set it to `autonamed-bookmark'.

Re: [External] : Re: A feature to go to last edit locations

[Jean Louis]

> > Given how much one moves during editing, I have hard time imagining
> > how a command that returns me to "the last place I edited" could be
> > useful without me telling Emacs which of those places is important and
> > which isn't.

That ispired me, thanks Eli.

> If you invent a mechanism to save "the last location" >
> automatically, you are going to add a facility that will have a high
> probability of false positives.

Exactly.

Then I have some buffers which are not tied to file name, temporary
buffers, but they may dwell for days, and I wish to go to them too.

If they disapear, then I have to implement self-destruction of such
point of non-existing buffer without file name.

> > In any case, whatever method of deducing automatically which place to
> > record, I think it's better to build the feature on top of registers,
> > since they are already equipped for saving and restoring
> > locations.

I had to implement it in the database quickly (DONE), as I have less
to think of. Previous ID, next ID and using one global or local
variable to keep the current point ID.

Food is good.

> FWIW, Bookmark+ has `bmkp-automatic-bookmark-mode', which
> just records locations with a timer delay.

That is also idea. Though it can't teach Emacs what user thinks.

And what about the point from where user went to other points, that
one should be recorded automatically, I guess, as how else can user go
back. 

>   If you want the automatic bookmarks to be temporary (not saved to your
>   bookmark file), then customize option

Definitely it is food for thought. Temporary bookmarks should be those
from where user jumped from, as example.

>   If you want the automatically created bookmarks to be highlighted,
>   then customize option `bmkp-auto-light-when-set' to highlight
>   bookmarks of the appropriate kind.  For example, to highlight
>   autonamed bookmarks set it to `autonamed-bookmark'.

Not that it is related, but I just imagine how specific part of text
could be highlighted, and then also bookmarked, and than point would
search for that text, and come there, and highlight it again.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: A feature to go to last edit locations

[Dmitry Gutov]

On 12/02/2023 19:41, Daniel Martín wrote:
> What do you think?  Third-party packages like goto-last-change.el [2] or
> session.el [3] (see session-jump-to-last-change) implement this feature
> in a per-buffer basis, but I wonder if we could do better and implement
> something that works across buffers.

I agree this kind of feature should work across buffers (and that's my 
main criticism of the global/local marks feature already).

I do wonder though if a separate new stack (with a set of assigned key 
bindings) is a good UI. Maybe we'd integrate it into xref navigation 
command stacks?

OTOH, some users might not want that exactly. So it could be customizable.

Re: A feature to go to last edit locations

[Daniel Martín]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 12/02/2023 19:41, Daniel Martín wrote:
>> What do you think?  Third-party packages like goto-last-change.el [2] or
>> session.el [3] (see session-jump-to-last-change) implement this feature
>> in a per-buffer basis, but I wonder if we could do better and implement
>> something that works across buffers.
>
> I agree this kind of feature should work across buffers (and that's my
> main criticism of the global/local marks feature already).
>
> I do wonder though if a separate new stack (with a set of assigned key
> bindings) is a good UI. Maybe we'd integrate it into xref navigation
> command stacks?
>

Yes, the xref navigation stack is exposed via Edit, Go To, Back/Forward,
so perhaps it can be extended to support tracking and going to previous
editing locations, if users enable an option.

Another question is how to track the edit locations efficiently.  A
naive implementation would be to add a function to
after-change-functions if the xref setting is enabled.

Re: A feature to go to last edit locations

[Dmitry Gutov]

On 12/02/2023 20:50, Daniel Martín wrote:
> Another question is how to track the edit locations efficiently.  A
> naive implementation would be to add a function to
> after-change-functions if the xref setting is enabled.

Sure, as one option. Except you'd have to differentiate user-made 
changes to the buffer and ones created by more complex commands, or 
timers, or auto-revert-mode...

Re: A feature to go to last edit locations

[Daniel Martín]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 12/02/2023 20:50, Daniel Martín wrote:
>> Another question is how to track the edit locations efficiently.  A
>> naive implementation would be to add a function to
>> after-change-functions if the xref setting is enabled.
>
> Sure, as one option. Except you'd have to differentiate user-made
> changes to the buffer and ones created by more complex commands, or
> timers, or auto-revert-mode...

That's why I think we should somehow leverage the undo information to
implement this feature.  But if we want to support multiple buffers,
we'd need to at least bookkeep additional information when Emacs adds
entries to buffer-undo-list.

Re: A feature to go to last edit locations

[Jean Louis]

* Dmitry Gutov <dgutov@yandex.ru> [2023-02-12 21:53]:
> On 12/02/2023 20:50, Daniel Martín wrote:
> > Another question is how to track the edit locations efficiently.  A
> > naive implementation would be to add a function to
> > after-change-functions if the xref setting is enabled.
> 
> Sure, as one option. Except you'd have to differentiate user-made changes to
> the buffer and ones created by more complex commands, or timers, or
> auto-revert-mode...

One could do following:

- remember paragraph at point
- split it as words
- record those words
- jump to point
- search in buffer upwards and downwards for some regex like word.*word.*word.*

Maybe that think process could help in locating the exact point.

Or point could remember also the few words or line, and search for it
straight, up or down.

If it does not exist, point should destroy itself by asking user for it.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: A feature to go to last edit locations

[Jean Louis]

* Dmitry Gutov <dgutov@yandex.ru> [2023-02-12 21:09]:
> On 12/02/2023 19:41, Daniel Martín wrote:
> > What do you think?  Third-party packages like goto-last-change.el [2] or
> > session.el [3] (see session-jump-to-last-change) implement this feature
> > in a per-buffer basis, but I wonder if we could do better and implement
> > something that works across buffers.
> 
> I agree this kind of feature should work across buffers (and that's my main
> criticism of the global/local marks feature already).

I was reading, thanks, it inspired me. 

But Eli said something important, why go somewhere back randomly, but
better going where user marked it to need it.

Now I get it with single click: S-C-<down> to record point and then
S-C-<left> and <right> to go to previous or next one.

It is using database, but it may serve for brainstorming. I also try
to use database tables to switch to them, instead of buffers with
files.

Emacs has SQLite built-in, this way of work could be used in future,
or package could easily be made.

It would persist over sessions without problems.

And I could make a switch that instead of moving over global points,
and buffers, to move only in single buffer.

(defvar rcd-db-emacs-point-id nil
  "Last Emacs point ID where user jumped to.")

(defun rcd-db-emacs-point-next ()
  "Go to next Emacs point."
  (interactive)
  (let ((next (rcd-db-emacs-point-to-go "next")))
    next))

(defun rcd-db-emacs-point-previous ()
  "Go to previous Emacs point."
  (interactive)
  (let ((previous (rcd-db-emacs-point-to-go "previous")))
    previous))

(defun rcd-db-emacs-point-go-to (id)
  "Go to Emacs point ID."
  (let ((point (rcd-db-table-id-hash "emacspoints" id cf-db)))
    (when (hash-table-keys point)
      (let ((buffer-name (gethash "emacspoints_buffername" point))
	    (file-name (gethash "emacspoints_bufferfilename" point))
	    (table (gethash "emacspoints_table" point))
	    (column (gethash "emacspoints_column" point))
	    (table-id (gethash "emacspoints_tableid" point))
	    (point (gethash "emacspoints_point" point)))
	(cond ((and buffer-name
		    (buffer-live-p (get-buffer buffer-name))
		    (not file-name)
		    (not table))
	       (switch-to-buffer buffer-name)
	       (goto-char point))
	      ((and buffer-name file-name
		    (buffer-live-p (get-buffer buffer-name))
		    (not table))
	       (switch-to-buffer buffer-name)
	       (goto-char point))
	      ((and buffer-name file-name
		    (not (buffer-live-p (get-buffer buffer-name)))
		    (not table))
	       (find-file file-name)
	       (goto-char point))
	      ((and buffer-name table column table-id
		    (buffer-live-p (get-buffer buffer-name)))
	       (switch-to-buffer buffer-name)
	       (goto-char point))
	      ((and buffer-name table column table-id
		    (not (buffer-live-p (get-buffer buffer-name))))
	       (hyperscope-edit-with-mode table-id column)
	       (switch-to-buffer buffer-name)
	       (goto-char point))
	      (t (rcd-message "Point ID %s not found" id)))))))

(keymap-global-set "M-s-<left>" #'rcd-db-emacs-point-previous)
(keymap-global-set "M-s-<right>" #'rcd-db-emacs-point-next)
(keymap-global-set "M-s-<down>" #'rcd-db-emacs-point-record)

(defun rcd-db-emacs-point-to-go (direction)
  "Return next Emacs point to go by using DIRECTION.

DIRECTION is string that may be \"previous\" or \"next\"."
  (when (string-match "^next$\\|^previous$" direction)
    (let ((last (rcd-sql-first "SELECT emacspoints_id FROM emacspoints ORDER BY emacspoints_id DESC LIMIT 1" cf-db))
	  (first (rcd-sql-first "SELECT emacspoints_id FROM emacspoints ORDER BY emacspoints_id ASC LIMIT 1" cf-db))
	  (message (format "No %s point found" direction))
	  (next (when (integerp rcd-db-emacs-point-id)
		  (rcd-sql-first 
		   "SELECT emacspoints_id FROM emacspoints WHERE emacspoints_id > $1 ORDER BY emacspoints_id ASC LIMIT 1" 
		   cf-db rcd-db-emacs-point-id)))
	  (previous (when (integerp rcd-db-emacs-point-id)
		      (rcd-sql-first 
		       "SELECT emacspoints_id FROM emacspoints WHERE emacspoints_id < $1 ORDER BY emacspoints_id DESC LIMIT 1" 
		       cf-db rcd-db-emacs-point-id))))
      (cond ((and (string= direction "previous") 
		  rcd-db-emacs-point-id
		  previous)
	     (rcd-db-emacs-point-go-to 
	      (setq rcd-db-emacs-point-id previous)))
	    ((and (string= direction "previous")
		  rcd-db-emacs-point-id
		  (null previous)
		  last)
	     (rcd-db-emacs-point-go-to 
	     (setq rcd-db-emacs-point-id last)))
	    ((and (string= direction "previous")
		  rcd-db-emacs-point-id
		  (null previous)
		  (null last))
	     (rcd-message message))
	    ((and (string= direction "next")
		  rcd-db-emacs-point-id
		  next)
	     (rcd-db-emacs-point-go-to 
	     (setq rcd-db-emacs-point-id next)))
	    ((and (string= direction "next")
		  rcd-db-emacs-point-id
		  (null next)
		  first)
	     (rcd-db-emacs-point-go-to 
	     (setq rcd-db-emacs-point-id first)))
	    (t (rcd-message message))))))

(defun rcd-db-emacs-point-record ()
  "Record Emacs point in the database."
  (interactive)
  (let* ((buffer-name (buffer-name))
	 (file-name (buffer-file-name))
	 (table rcd-db-current-table)
	 (column rcd-db-current-column)
	 (table-id rcd-db-current-table-id)
	 (db-handle rcd-db-current-database-handle)
	 (db-name (cond ((and db-handle (rcd-sql-first "SELECT current_database()" db-handle))
			(t nil))))
	 (point (point))
	 (name (cond (current-prefix-arg (rcd-ask-get "Point name: "))
		     (table (format "DB: %s, table: %s, column: %s, ID: %s"
				    db-name table column table-id))
		     ((not file-name) (format "Buffer: %s" buffer-name))
		     (t (format "File: %s" file-name))))
	 (description (cond (current-prefix-arg (sql-escape-string (rcd-ask "Point description: ")))
			    (t "NULL")))
	 (table-uuid (when (and table-id
				(rcd-db-uuid-by-id table table-id cf-db))
			    (rcd-db-uuid-by-id table table-id cf-db))))
    (rcd-sql-first 
     (format "INSERT INTO emacspoints 
              (emacspoints_name, emacspoints_description, emacspoints_buffername, emacspoints_bufferfilename, emacspoints_dbname,
               emacspoints_table, emacspoints_column, emacspoints_tableid, emacspoints_tableuuid, emacspoints_point)
              VALUES ($1, %s, $2, %s, %s, %s, %s, %s, %s, $3)
              ON CONFLICT DO NOTHING
              RETURNING emacspoints_id" description 
	      (sql-escape-string-or-null file-name) (sql-escape-string-or-null db-name)
	      (sql-escape-string-or-null table) (sql-escape-string-or-null column) (or table-id "NULL")
	      (sql-escape-string-or-null table-uuid))
     cf-db name buffer-name point)))

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: A feature to go to last edit locations

[Dmitry Gutov]

On 13/02/2023 21:24, Jean Louis wrote:
> But Eli said something important, why go somewhere back randomly, but
> better going where user marked it to need it.

Because by the time the user knows they need to go back, they might have 
missed the opportunity to mark the place.

Re: A feature to go to last edit locations

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]


Dmitry Gutov <dgutov@yandex.ru> writes:

> On 13/02/2023 21:24, Jean Louis wrote:
>> But Eli said something important, why go somewhere back randomly, but
>> better going where user marked it to need it.
>
> Because by the time the user knows they need to go back, they might
> have missed the opportunity to mark the place.

That’s why I like dumb-jump-back so much. dumb-jump / xref is a
cross-file command. C-M-g gets me to another file. C-M-p gets me back
where I jumped off.

A command that jumps into some other file like go-to-reference or
go-to-definition is a natural recording point. After jumping multiple
times I have a linked list of jump-locations to which I can jump back in
order. As a model that works much better than plain movement recording
in IntelliJ and also somewhat better than edit-locations. (though edit
locations could still be useful — but changing the buffer when going
back through edits can blur the sense which file I’m in at the moment)

If I switch buffers with switch-buffer, I know where I came from. If I
switch with a command, I am likely to quickly jump through multiple
files. So those jump-to-other-file commands are natural recording
points.

When I run xref, this is the point in a file where I’m likely to want to
return to.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: A feature to go to last edit locations

[Jean Louis]

* Dmitry Gutov <dgutov@yandex.ru> [2023-02-13 22:43]:
> On 13/02/2023 21:24, Jean Louis wrote:
> > But Eli said something important, why go somewhere back randomly, but
> > better going where user marked it to need it.
> 
> Because by the time the user knows they need to go back, they might have
> missed the opportunity to mark the place.

Yes, right.

Drew mentioned "temporary bookmark", and I implemented it in my system
already:

Instead of this:

(defun rcd-db-emacs-point-next ()
  "Go to next Emacs point."
  (interactive)
  (let ((next (rcd-db-emacs-point-to-go "next")))
    next))

I made this:

(defun rcd-db-emacs-point-next ()
  "Go to next Emacs point."
  (interactive)
  (rcd-db-emacs-point-record t)
  (let ((next (rcd-db-emacs-point-to-go "next")))
    next))

and then

(defun rcd-db-emacs-point-record (&optional temporary)
  "Record Emacs point in the database."
  (interactive)
  (let* ((buffer-name (buffer-name))

As if I am jumping now from this temporary mail buffer, even this is
recorded, I can come back from jump, very handy.

It is similar to changing buffers or browsing bookmarks in circle.

When storing it in the database, it is possible to list it:

 30         File: /home/data1/protected/Programming/emacs-lisp/rcd-cf.el
 33         Buffer: RCD Notes Dashboard
 35         Buffer: RCD Notes Dashboard
 47         Buffer: RCD Notes Dashboard
 65         File: /home/data1/protected/Programming/Software/emacs/lisp/windmove.el

And then user could just mark some of them, and designate a "narrow
session", a narrowed ring of files, buffers through which one can
float, or move from one to each other, but not to something else.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: A feature to go to last edit locations

[Eli Zaretskii]

> Date: Mon, 13 Feb 2023 21:41:19 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> On 13/02/2023 21:24, Jean Louis wrote:
> > But Eli said something important, why go somewhere back randomly, but
> > better going where user marked it to need it.
> 
> Because by the time the user knows they need to go back, they might have 
> missed the opportunity to mark the place.

The important question is: which of these two failures could happen
more frequently?  IME, wading through gobs of places I never wanted to
go back to is no fun.

RE: [External] : Re: A feature to go to last edit locations

[Drew Adams]

> > > But Eli said something important, why go somewhere back randomly, but
> > > better going where user marked it to need it.
> >
> > Because by the time the user knows they need to go back, they might have
> > missed the opportunity to mark the place.
> 
> The important question is: which of these two failures could happen
> more frequently?  IME, wading through gobs of places I never wanted to
> go back to is no fun.

I agree.

But some people apparently do want zillions of places noted,
"just in case" they want to return to one of them.  That's
why I added an automatic bookmarking mode, which creates
bookmarks periodically, provided the distance from all other
automatic bookmarks is at least at least an option value:

  bmkp-automatic-bookmark-min-distance is a variable defined
  in `bookmark+-1.el'.

  Its value is 1000

  Documentation:
  Minimum number of chars between automatic bookmark positions.

The period is also an option:

  bmkp-automatic-bookmark-mode-delay is a variable defined
  in `bookmark+-1.el'.

  Its value is 60

  Documentation:
  Number of seconds delay before automatically setting a bookmark.

I mention this in case it helps someone working on something
similar.  There are many ways to save some position (and other
things - desktops were mentioned).  Bookmarks are one way (and
they have certain advantages).

RE: [External] : Re: A feature to go to last edit locations

[Drew Adams]

> > > > But Eli said something important, why go somewhere back randomly,
> but
> > > > better going where user marked it to need it.
> > >
> > > Because by the time the user knows they need to go back, they might
> have
> > > missed the opportunity to mark the place.
> >
> > The important question is: which of these two failures could happen
> > more frequently?  IME, wading through gobs of places I never wanted to
> > go back to is no fun.
> 
> I agree.
> 
> But some people apparently do want zillions of places noted,
> "just in case" they want to return to one of them.  That's
> why I added an automatic bookmarking mode, which creates
> bookmarks periodically, provided the distance from all other
> automatic bookmarks is at least at least an option value...

Somewhat more useful, perhaps, but closely related, there
are two specializations of this feature: one to automatically
bookmark Info nodes you visit, and one to do that for web
pages you visit (with EWW).  For example, for Info:

  bmkp-info-auto-bookmark-mode is an interactive Lisp function in
  'bookmark+-1.el'.

  (bmkp-info-auto-bookmark-mode &optional ARG)

  Toggle automatically setting a bookmark when you visit an Info node.
  The bookmark name is "(MANUAL) `NODE'", where:

   MANUAL is the name of the current manual (the base file name).
   NODE is the name of the current node.

  If option `bmkp-info-auto-type' is `create-or-update' then such a
  bookmark is created for the node if none exists.  If the option value
  is `update-only' then no new bookmark is created automatically, but an
  existing bookmark is updated.  (Updating a bookmark increments the
  recorded number of visits.)  You can toggle the option using
  `M-x bmkp-toggle-info-auto-type'.

And you can sort/access Info bookmarks that you've visited most
or least etc.  This is one of the advantages of bookmarks: they
do things like record the number of visits, time of last visit,
etc.	

Re: [External] : Re: A feature to go to last edit locations

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2023-02-14 07:58]:
> And you can sort/access Info bookmarks that you've visited most or
> least etc.

That is good feature. 

I have made more stronger generalization and defined elementary
objects.

Elementary Objects:
https://www.dougengelbart.org/content/view/110/460/#2a1a

One could think of it as bookmarks, but they are not (only). Objects
can be chunks of text, word, paragraph, PDF, PDF by page, Message-ID,
Video, Video at time, anything which is defined by user.

It is true that I can jump to it, I can insert it in text, or make
reports, project documents, convert to hyperlinks and similar.

How is object activated, can be also defined by user. It is not hard
coded. Function can be inserted in the database by administrator.

With only little work I can upgrade it that function can be inserted
for each user differently. Somebody may want to open PDF file with PDF
viewer, somebody may want PDF file moved to server first and then
opened. There are currently no people who would need that remote
collaborative feature.

Similarly like you, I use one global rank, integer that increases when
user reads document, when document is shared, when it is activated,
visited.

It is useful as to quicker find relevant documents.

I search for documents by relevant words and find 17 of them, but the
most relevant appears on top, as it got its rank X, indicating it was
mostly used in past.

> This is one of the advantages of bookmarks: they do things like
> record the number of visits,

Thanks, good idea, that is rank on my side It increases with visit,
edit, etc.

> time of last visit, etc.

When moving between objects, I have "ring" in the database, this makes
it possible to visually reconstruct what was done, visited, by any
single day by which individual collaborative user. That is similar to
"last visit" only related to any kind of object, need not be bookmark.

Is not same as "Emacs Places" where such points are not important to
be recorded by name, even though they have name.

Time of last activation (visit) I keep also in a general log, that can
have more human like titles like "Activated Twids Telecom"

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

RE: [External] : Re: A feature to go to last edit locations

[Drew Adams]

> > And you can sort/access Info bookmarks that you've visited most or
> > least etc.
> 
> That is good feature. I have made more stronger
> generalization and defined elementary objects.
> One could think of it as bookmarks, but they are
> not (only). Objects can be chunks of text, word,
> paragraph, PDF, PDF by page, Message-ID, Video,
> Video at time, anything which is defined by user.

Same with bookmarks.  You can bookmark anything Emacs can know or reach.  And without defining anything you can bookmark regions and (if you use library zones.el) sets of regions (zones).

> It is true that I can jump to it, I can insert it in text, or make
> reports, project documents, convert to hyperlinks and similar.
> 
> How is object activated, can be also defined by user. It is not hard
> coded. Function can be inserted in the database by administrator.

Same with bookmarks.  "Jumping to" a bookmark can mean/do anything.
A bookmark is essentially a named, usually-persistent closure.

> When moving between objects, I have "ring" in the database, this makes
> it possible to visually reconstruct what was done, visited, by any
> single day by which individual collaborative user. That is similar to
> "last visit" only related to any kind of object, need not be bookmark.

Maybe (maybe not) your rings are like Bookmark+'s feature of letting you cycle among any set of bookmarks, either direction.  Cycling usually means "jumping", but it can mean doing anything at all to/with the bookmarks.

https://www.emacswiki.org/emacs/BookmarkPlus#BookmarkNavigationList

> Time of last activation (visit) I keep also in a general log

A general log is what bookmarks intentionally get away from.

A feature of the basic design of bookmarks is that info about a thing - or one aspect/view/set-of-info about a thing - is stored in a record in a bookmark file, which is totally separate from whatever might store that thing itself.  And you can have any number of bookmark files.  And the same bookmark can be in any number of bookmark files.

Re: [External] : Re: A feature to go to last edit locations

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2023-02-14 19:24]:
> > > And you can sort/access Info bookmarks that you've visited most or
> > > least etc.
> > 
> > That is good feature. I have made more stronger
> > generalization and defined elementary objects.
> > One could think of it as bookmarks, but they are
> > not (only). Objects can be chunks of text, word,
> > paragraph, PDF, PDF by page, Message-ID, Video,
> > Video at time, anything which is defined by user.
> 
> Same with bookmarks.  You can bookmark anything Emacs can know or
> reach.  And without defining anything you can bookmark regions and
> (if you use library zones.el) sets of regions (zones).

I did not know. I will use it as food thought.

I see it is excellent:
https://www.emacswiki.org/emacs/BookmarkPlus

I did not research it well, tried short, and did not research. You
have done good work. Because I have not research it, I did not know
it.

I am following the design here:

Elementary Objects:
https://www.dougengelbart.org/content/view/110/460/#2a1a

Then it becomes so similar to the work with "Bookmark+" library.

There are several nice features that I have to duplicate to adapt for
RCD Notes & Hyperscope for Emacs.

The last "Emacs Points" were not meant to be bookmarks, more like a
list of global and local locations which user may use to move there
and forth.

In general we have similar features, you call it bookmarks, I call it
Hyperdocuments and objects.

Purpose of our work is not same. My objects can be for example Org
objects, it would be non-file database entry. I do not think that
Bookmark+ has been designed to hold for example LaTeX.

I like and understand your writing, like here in example:

> * You can combine bookmarks, to make composite, or sequence,
>  bookmarks. Invoking a sequence bookmark invokes each of its component
>  bookmarks in turn. A component bookmark can itself be a sequence
>  bookmark.

I have it same, I can combine, or find interesection of elementary
objects, I can mark what I need or take all list of visible ones and
make new object contaning all those.

What is to be done with the object is decided by it's type and
subtype.

I understand that ideas spring up in my mind which you read and then
say "Hey, that already exists in Bookmark+", but I did not know.

Even then, objects are saved in the database, and related to planning,
and represent themselves notes, tasks, not just bookmarks pointing to
notes and tasks, they are related to people, can be shared and so I
canot reuse your library, apart from reusing ideas, food for thought.

I am trying to find all the 70 types, and I tried this to see it:

(insert (format "%s" bmkp-types-alist))((autofile
. bmkp-autofile-history) (autonamed . bmkp-autonamed-history)
(bookmark-file . bmkp-bookmark-file-history) (bookmark-list
. bmkp-bookmark-list-history) (desktop . bmkp-desktop-history) (dired
. bmkp-dired-history) (dired-this-dir . bmkp-dired-history) (eww
. bmkp-eww-history) (file . bmkp-file-history) (file-this-dir
. bmkp-file-history) (gnus . bmkp-gnus-history) (image
. bmkp-image-history) (info . bmkp-info-history) (local-file
. bmkp-local-file-history) (man . bmkp-man-history) (non-file
. bmkp-non-file-history) (region . bmkp-region-history) (remote-file
. bmkp-remote-file-history) (snippet . bmkp-snippet-history)
(specific-buffers . bmkp-specific-buffers-history) (specific-files
. bmkp-specific-files-history) (temporary . bmkp-temporary-history)
(url . bmkp-url-history) (variable-list . bmkp-variable-list-history))

I have found these 24 possible completions:

autofile autonamed bookmark-file bookmark-list desktop dired
dired-this-dir eww file file-this-dir gnus image info local-file man
non-file region remote-file snippet specific-buffers specific-files
temporary url variable-list

I would like to see those 70 types.

I have tried invoking function:

> Bookmark+ adds over 70 types of bookmark. (You can see what they all
> are by invoking function ‘bmkp-types-alist’.)

But that does not seem to be the function, it is alist, but I do not
see 70 types.

I fully agree to the idea of bookmarks how you expanded the feature. 

Can you save window configuration over session? I would like to do
that. That is not same as desktop which is slow and cannot narrow to
window configuration.

Defining user types is clear to me, though not as easy. 

With objects I can also change their types and subtypes at any time.

And there is the notion of a set, to go inside of the set of objects,
into the subtree. I believe it is possible in bookmarks+ too.

The work you have done in general is easier managed by using the
database. That way it could become easily collaborative Hyperdocument
management.

I have tagging too, so it would be trivial function to start tagging
single or multiple files in Dired, as all files would be slurped
automatically as Hyperdocuments or elementary objects into the Dynamic
Knowledge Repository and Emacs would only ask me for tags. Those
existing files in the database would be re-used.

You have done great documentation and I have also to start doing it
for my software.

There are many similar features developed from my side.

- capturing region (bookmarking) I did not do, it would be one minute
  to implement it.

- snippet to kill ring, I have that all and use it very often. Object
  has name (which could be arbitrary long), description, text, report,
  internal report, hyperlink, arguments, and many other
  properties. Then many times I need name+link, or
  name+description+link, or name + text, or only text in kill ring,
  that is single key. Often I want it inserted in the side window.

- I also have marking, deleting, activatig (jumping to), but my
  objects can be any type of markup, they are like files but in the
  database, but can point in different types to files on the file
  system

- In fact file in file system is not what I remember, I work almost
  exclusively with the Dynamic Knowledge Repository and not with file
  sytem directly. 

- No matter what is the type or subtype, I have made function to list
  all bookmarks of the type where cursor is positioned. You have made
  all the special functions or commands in menu to jump to those
  types or show list of interesection. If I press C-u then I am asked
  for types, but otherwise I can list by types or subtypes depending
  where is cursor.

- I strive to make automatic functions, automatic keybindings,
  automated menus. If thers is new type, that shall appear
  automatically. The key binding may be explained uniquely in the type
  data itself, not in Emacs Lisp program, but in the
  database. Database can make sure it is unique.

As your thinking and design was straight forward, I have to use this
page for my learning and adaptation, to make RCD Notes & Hyperscope
for GNU Emacs more straight forward.

Bookmark+ by Drew Adams:
https://www.emacswiki.org/emacs/BookmarkPlus

My personal work is rather capricious and not necessarily
systematic. The system works, that is what matters, development is not
for purpose of development or pleasing others but for business
needs. Though one day it will come out.

Features are listed here:

RCD Notes & Hyperscope for GNU Emacs, The Dynamic Knowledge Repository:
https://gnu.support/gnu-emacs/rcd-notes-for-gnu-emacs/index.html

> > It is true that I can jump to it, I can insert it in text, or make
> > reports, project documents, convert to hyperlinks and similar.
> > 
> > How is object activated, can be also defined by user. It is not hard
> > coded. Function can be inserted in the database by administrator.
> 
> Same with bookmarks.  "Jumping to" a bookmark can mean/do anything.
> A bookmark is essentially a named, usually-persistent closure.

Some of my often used cases:

- With markup Asciidoctor or LaTeX, etc., jumping fetch the text from
  database, creates the PDF, and displays it. It is file which is not
  on file system and it's PDF or HTML is generated at each new "jump"
  which I call "Activation". Object get it's file name automatically,
  usually the UUID or ID, or user can assign file name.

  Another type of activation is sharing, there is sharing to related
  people, or those not yet related. Related people are more
  important. Then objects may be shared by using E-mail, XMPP, SMS,
  anyhow. If necessary object may be published and then it's URL
  shared with the related or unrelated person. Any unrelated person
  becomes related with tag similar to "INFORMED BY EMAIL".

  Then any markup can be converted any how, so it is quite possible
  for me to mix Asciidoctor, text, Markdown, Org, txt2tags,
  reStructuredText how I wish, this is because objects are separate
  and markup conversions can be defined in separate list. If the
  mixed-object Hyperdocument has LaTeX markup, all the consisting
  elementary objects would be converted from their markup to main
  LaTeX markup, as example.

In general my system is used for people relationship management and
business project management and planning.

> > When moving between objects, I have "ring" in the database, this makes
> > it possible to visually reconstruct what was done, visited, by any
> > single day by which individual collaborative user. That is similar to
> > "last visit" only related to any kind of object, need not be bookmark.
> 
> Maybe (maybe not) your rings are like Bookmark+'s feature of letting
> you cycle among any set of bookmarks, either direction.  Cycling
> usually means "jumping", but it can mean doing anything at all
> to/with the bookmarks.

I like to cycle through buffers or just cycling over names of objects
(Hyperdocuments) with single key "." or "," for forward and
backward. Because elementary objects are in their sets, the cycling
becomes litle more semantic.

Though the single ring point of the "cycle" has it's date creation,
that means I could derive it to the list of all viewed, tackled,
activating, edited Hyperdocuments of that day, or even hour. This
implies that work of the day can be seen.

People section is interesting and communication center, it is like
call center. All the 100 last people with communication are shown and
then this helps visually that they do not get lost. People are ranked
too, it is easy to get list of 200 or 1000 people who matters, and
initiate calls, SMS, XMPP, e-mails with them. 

> https://www.emacswiki.org/emacs/BookmarkPlus#BookmarkNavigationList
> 
> > Time of last activation (visit) I keep also in a general log
> 
> A general log is what bookmarks intentionally get away from.
> 
> A feature of the basic design of bookmarks is that info about a
> thing - or one aspect/view/set-of-info about a thing - is stored in
> a record in a bookmark file, which is totally separate from whatever
> might store that thing itself.  And you can have any number of
> bookmark files.  And the same bookmark can be in any number of
> bookmark files.

I understand it the notion behind it.

General log is used on my side for human to spot patterns and needs of
a human, as that way I can see which actions are repeated or what
could be integrated better.

That bookmarked was activated (jumped to) is stored in the ring table,
separate list of data, and also in hyperdocumentactions table, though
there are many ways of tackling objects, some are edited heavily as
they, some are never edited only jumped to, some are tagged, some have
timestamps, people related, too many things. Those different
timestamps get automatically generated in those other different
tables. They can serve as information what was done in past with which
object. Putting that huge information in single object would be on my
side overkill.

If it is only simple one like "last jumped to", it works without
problem.

It is of course best when everything is stored in the object. With
complexities that becomes less helpful. Example is having objects with
20 different markups, 101 types, and 107 subtypes. How many
combinations are those? I am using about 305 combinations, but do not
believe that is a total number. And this is only one example among
many others.

Now if I keep that "type" stored in the same data object, that would
imply that my program need to know about that type, it implies I must
program the type, and work on it.

Isn't it better having types, subtypes, however we call it, to be in a
separate list, and then let the user define what to do based on that
type. Normally it is simple function like (hyperscope-evince hs::id)
which would open up PDF indexed (bookmarked).

The notion comes from relational database principles, tables are
related. Keeping it in single table is possible, though makes things
with development rather harder, as it demands programmer to program.

Instead one can make user to define user's extension, and basic
program remains the same.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

RE: [External] : Re: A feature to go to last edit locations

[Drew Adams]

Your msg is very long, and is getting (or is)
off-topic.  I replied to some of what you wrote
here.

> https://urldefense.com/v3/__https://www.dougengelbart.org/content/view/110
> /460/*2a1a__;Iw!!ACWV5N9M2RV99hQ!K4ZMzQdLs-
> jMoDjFBEzqIHwTyvrkh3Lnkzh51eINtJK2sVxrkpv-h1NODDZd0Yuem0trawHNFVtYnTOo$

Thanks for the link.

> My objects can be for example Org
> objects, it would be non-file database entry. I do not think that
> Bookmark+ has been designed to hold for example LaTeX.

Bookmark+ uses the vanilla Emacs design for
bookmarks.  It defines some new types of bookmarks,
and changes some of the plumbing.

Emacs bookmarks can "hold" anything you like.  For
bookmarks that you want to persist, the "anything"
needs to be persistable and readable.

But typically bookmarks don't "hold" much data.
Instead, they point to data that's available
somewhere else (whether it's persisted or not at
that "somewhere else").

There should be no inherent problem bookmarking a
"non-file database entry".  You just have to
decide what you need to put in the bookmark, to
later get to it (e.g. restore it).

Bookmark targets need not be things you can open
in Emacs - a bookmark, like any Emacs function,
can invoke actions/commands outside Emacs.

Even vanilla bookmarks can jump to nonfile things.
Bookmark+ adds some such, and enhances others.
Dired bookmarks are a good example of bookmarking
a nonfile "location"/thing.  Jumping to one restores
the Dired state of the time of bookmarking (markings,
hidden files, omitted files, ls switches, inserted
subdirs, etc.).

You can even bookmark things for which there's no
way to "jump" to - no way to invoke the bookmark.
Or for which you never want/need/bother to invoke
the bookmark.  

You can sort, edit, tag – whatever non-invokable
bookmarks, i.e., you can use bookmarks just to
organize things.  (And you have bookmarks that
are invokable only in certain contexts.)

> I have it same, I can combine, or find interesection of elementary
> objects, I can mark what I need or take all list of visible ones and
> make new object contaning all those.

Bookmark tags are a good way to categorize things
and access them by combinations of such categories.

https://www.emacswiki.org/emacs/BookmarkPlus#BookmarkTags

> What is to be done with the object is decided by it's type and
> subtype.
> I understand that ideas spring up in my mind which you read and then
> say "Hey, that already exists in Bookmark+", but I did not know.

There are no doubt other Emacs features (both
vanilla and from other libraries) that let you do
similar/overlapping things.  And of course any
time two things are different (which is what makes
them two things, not one), there are pros and cons
for each.

Org mode, for example, lets you embed different
kinds of things in an Org buffer/file.  You can
tag them, link them, annotate them, and act on
them in any number of ways.  A big difference here
is that the info/data of the things, and the tags
and links and annotations... are in the Org file,
along with the other things and any "main" text.

That has some advantages, no doubt.  But storing
annotations, links, tags, actions, other metadata,
... separately (e.g. in a bookmark file) also has
(different) advantages.

The implementation of bookmarks, as text files of
Lisp code, is fine for many use cases.  It fits
the use of any number of bookmark files, each of
which is not gigantic.

But yes, Someone (TM), sometime, will hopefully
do things such as:

1. Allow (also) for binary ("compiled") bookmark
   formats (and thus files).

2. Allow storing and accessing bookmarks using
   (multiple) databases.

3. ... (?)

Think of JSON, for example.  As a standard, it's
defined only textually.  But there are multiple
binary JSON formats as well, and without them
many uses of JSON wouldn't be feasible.  Same
with XML.

> Even then, objects are saved in the database, and related to planning,
> and represent themselves notes, tasks, not just bookmarks pointing to
> notes and tasks, they are related to people, can be shared and so I
> canot reuse your library, apart from reusing ideas, food for thought.

Not clear to me.  Why would notes, etc., whether
related to people or not, be something you can't
leverage bookmarks for?  I don't doubt you're
saying something true, but it's not clear to me
what it is.

(No need to follow up with an explanation.  This
is already likely off-topic etc.)

> > Bookmark+ adds over 70 types of bookmark. (You
> > can see what they all are by invoking function
> > ‘bmkp-types-alist’.)
> 
> But that does not seem to be the function, it is
> alist, but I do not see 70 types.

No, it's a function, not a variable.  The function
returns an alist of known types (their names) and
the associated history list (for completion).  It's
a function because which predefined types exist
depends on your environment, e.g., on whether you
have this or that other library, and on what Emacs
release you have.

It's not very important what predefined types exist.
The predefined types, and the functions etc. that
leverage them, are conveniences.  You can say they
belong to the top-level cruft of Bookmark+, not to
the basic design/features.

What's important is that it's easy for you to define
new types.  The predefined types are usable OOTB,
for things like jumping to a bookmark of a given
type, or choosing a navigation list of bookmarks of
a given type.

FWIW, (bmkp-types-alist) shows this, for me:

(("non-invokable" . bmkp-non-invokable-history)
 ("some-tags" . bmkp-some-tags-history)
 ("bookmark-list" . bmkp-bookmark-list-history)
 ("file-this-dir-all-tags"
  . bmkp-file-this-dir-all-tags-history)
 ("desktop" . bmkp-desktop-history)
 ("untagged" . bmkp-untagged-history)
 ("specific-files" . bmkp-specific-files-history)
 ("sequence" . bmkp-sequence-history)
 ("all-tags" . bmkp-all-tags-history)
 ("image" . bmkp-image-history)
 ("specific-buffers" . bmkp-specific-buffers-history)
 ("file" . bmkp-file-history)
 ("last-specific-buffer"
  . bmkp-last-specific-buffer-history)
 ("local-file" . bmkp-local-file-history)
 ("autonamed-this-buffer"
  . bmkp-autonamed-this-buffer-history)
 ("regexp-filtered-tags"
  . bmkp-regexp-filtered-tags-history)
 ("temporary" . bmkp-temporary-history)
 ("file-this-dir-all-tags-regexp"
  . bmkp-file-this-dir-all-tags-regexp-history)
 ("non-dir-file" . bmkp-non-dir-file-history)
 ("dired-wildcards" . bmkp-dired-wildcards-history)
 ("regexp-filtered-file-name"
  . bmkp-regexp-filtered-file-name-history)
 ("this-buffer" . bmkp-this-buffer-history)
 ("eww" . bmkp-eww-history)
 ("omitted" . bmkp-omitted-history)
 ("regexp-filtered-annotation"
  . bmkp-regexp-filtered-annotation-history)
 ("this-file" . bmkp-this-file-history)
 ("region" . bmkp-region-history)
 ("info" . bmkp-info-history)
 ("tagged" . bmkp-tagged-history)
 ("remote-non-dir-file"
  . bmkp-remote-non-dir-file-history)
 ("file-some-tags-regexp"
  . bmkp-file-some-tags-regexp-history)
 ("autofile-some-tags"
  . bmkp-autofile-some-tags-history)
 ("bookmark-file" . bmkp-bookmark-file-history)
 ("url-browse" . bmkp-url-browse-history)
 ("non-file" . bmkp-non-file-history)
 ("orphaned-remote-file"
  . bmkp-orphaned-remote-file-history)
 ("man" . bmkp-man-history)
 ("file-this-dir" . bmkp-file-this-dir-history)
 ("file-all-tags-regexp"
  . bmkp-file-all-tags-regexp-history)
 ("orphaned-local-file"
  . bmkp-orphaned-local-file-history)
 ("autofile-all-tags"
  . bmkp-autofile-all-tags-history)
 ("some-tags-regexp" . bmkp-some-tags-regexp-history)
 ("file-some-tags" . bmkp-file-some-tags-history)
 ("url" . bmkp-url-history)
 ("variable-list" . bmkp-variable-list-history)
 ("file-this-dir-some-tags-regexp"
  . bmkp-file-this-dir-some-tags-regexp-history)
 ("dired" . bmkp-dired-history)
 ("icicles-search-hits"
  . bmkp-icicles-search-hits-history)
 ("annotated" . bmkp-annotated-history)
 ("autofile-all-tags-regexp"
  . bmkp-autofile-all-tags-regexp-history)
 ("local-non-dir-file"
  . bmkp-local-non-dir-file-history)
 ("file-all-tags" . bmkp-file-all-tags-history)
 ("all-tags-regexp" . bmkp-all-tags-regexp-history)
 ("autonamed" . bmkp-autonamed-history)
 ("orphaned-file" . bmkp-orphaned-file-history)
 ("non-autonamed" . bmkp-non-autonamed-history)
 ("buffer" . bmkp-buffer-history)
 ("remote-file" . bmkp-remote-file-history)
 ("gnus" . bmkp-gnus-history)
 ("lighted" . bmkp-lighted-history)
 ("function" . bmkp-function-history)
 ("this-file/buffer" . bmkp-this-file/buffer-history)
 ("snippet" . bmkp-snippet-history)
 ("this-buffer-lighted"
  . bmkp-this-buffer-lighted-history)
 ("file-this-dir-some-tags"
  . bmkp-file-this-dir-some-tags-history)
 ("w3m" . bmkp-w3m-history)
 ("dired-this-dir" . bmkp-dired-this-dir-history)
 ("regexp-filtered-bookmark-name"
  . bmkp-regexp-filtered-bookmark-name-history)
 ("autofile-some-tags-regexp"
  . bmkp-autofile-some-tags-regexp-history)
 ("autofile" . bmkp-autofile-history)
 ("last-specific-file"
  . bmkp-last-specific-file-history))

> Can you save window configuration over session? I would like to do
> that. That is not same as desktop which is slow and cannot narrow to
> window configuration.

That's one of my wishes too.

Last time I checked, window configs are not Lisp
readable.  I tried to get Emacs (Juanma, who did
the desktop restore stuff) to raise window and
frame configs to the level of Lisp-readable
thingies (so persistable) - but to no avail.

See, e.g., bug #14964 (also #10348).

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=14964#11

  I would also like to see functions that accept
  or produce window and frame configurations
  optionally accept and produce also Lisp-readable
  equivalents.

  IOW, today, such configurations always use actual
  window and frame objects, which are not Lisp-readable.
  I would like to see them optionally (e.g. via optional
  arguments) use Lisp-readable frame and window states.
  IOW, make it simple to persist such configurations.
  ...

  [Juanma's] work with desktop.el will apparently use
  Lisp-readable representations of sets of frames.
  I hope this will be applied/extended to the
  frame-configuration functions, so we can optionally
  get Lisp-readable frame configurations (with the same
  properties and interfaces as we have now).
  E.g., a frame config would continue to look like this,
  even when Lisp-readable:

  (frame-configuration FRAME+WINDOW-CONFIG...)

  where FRAME+WINDOW-CONFIG would be a Lisp-readable
  representation of a frame (a set of frame parameters,
  preferably at least the same ones recorded now) plus
  the frame's window configuration.

  And likewise for window configurations.  We have
  `window-state-(get|put)', but I would also like to
  see Lisp-readable window configurations.  IOW, wrap
  with (window-configuration...) what `window-state-get'
  with non-nil WRITABLE arg returns.

That suggestion was rejected.  I don't think, but
dunno for sure, that this is still the case: no
persistable, Lisp-readable frame and window configs.

HTH.

Re: A feature to go to last edit locations

[Dmitry Gutov]

On 14/02/2023 05:25, Eli Zaretskii wrote:
>> Date: Mon, 13 Feb 2023 21:41:19 +0200
>> From: Dmitry Gutov<dgutov@yandex.ru>
>>
>> On 13/02/2023 21:24, Jean Louis wrote:
>>> But Eli said something important, why go somewhere back randomly, but
>>> better going where user marked it to need it.
>> Because by the time the user knows they need to go back, they might have
>> missed the opportunity to mark the place.
> The important question is: which of these two failures could happen
> more frequently?  IME, wading through gobs of places I never wanted to
> go back to is no fun.

I guess that consideration is why "goto last change" is a separate 
command in IntelliJ, rather than having it incorporated into regular 
navigation.

RE: [External] : Re: A feature to go to last edit locations

[Drew Adams]

> Eli said something important, why go somewhere back randomly, but
> better going where user marked it to need it.
         ^^^^^^^^^^^^^^^^^^^^^^^
> Now I get it with single click: S-C-<down> to record point and then
> S-C-<left> and <right> to go to previous or next one.

You are reinventing (part of) what bookmarks do.

If you don't want to have to name bookmarks for this, then you can use autonamed bookmarks:

https://www.emacswiki.org/emacs/BookmarkPlus#AutonamedBookmarks

(Single key to set, single key to jump to.)

For that you need Bookmark+, but as an alternative you can just define a bookmark-setting command that provides default names of your own design.

Rolling your own thingies which are essentially just bookmarks (and using a database to store them, no less) is really not necessary. It may be fun to do, but Emacs already has what you describe, as bookmarks.

Re: [External] : Re: A feature to go to last edit locations

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]


Drew Adams <drew.adams@oracle.com> writes:

>> Eli said something important, why go somewhere back randomly, but
>> better going where user marked it to need it.
>          ^^^^^^^^^^^^^^^^^^^^^^^
>> Now I get it with single click: S-C-<down> to record point and then
>> S-C-<left> and <right> to go to previous or next one.
>
> You are reinventing (part of) what bookmarks do.
>
> If you don't want to have to name bookmarks for this, then you can use autonamed bookmarks:
>
> https://www.emacswiki.org/emacs/BookmarkPlus#AutonamedBookmarks

With C-x r f <KEY> there’s something even more powerful: save the full
frame configuration to a register (for example before starting a hunt
towards some reference or investigating something in depth).

Then use C-x r j <KEY> to restore the precise frame configuration with
buffers and buffer locations.

If you pair that with exwm, it provides you precise snapshots of desktop
configurations.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

RE: [External] : Re: A feature to go to last edit locations

[Drew Adams]

> With C-x r f <KEY> there’s something even more powerful: save the full
> frame configuration to a register (for example before starting a hunt
> towards some reference or investigating something in depth).
> 
> Then use C-x r j <KEY> to restore the precise frame configuration with
> buffers and buffer locations.
> 
> If you pair that with exwm, it provides you precise snapshots of desktop
> configurations.

Oh, you want not only to go to some position in some buffer.  You also want to restore a desktop?  Sure, no problem.

With Bookmark+ you can also _bookmark a desktop_ by hitting a key.  Have as many such bookmarks as you like.

That doesn't, alone, return you to any particular position.

But there are also "sequence bookmarks", which just invoke any number of bookmarks in sequence.  It's trivial to define a command that creates a sequence bookmark that specifically: (1) creates a desktop bookmark and (2) bookmarks the current position.

And it's trivial to define a command that jumps to such a sequence bookmark.  

[That already exists in a general way, in that you can use command `bmkp-jumpt-to-type' and choose `sequence' at the completion prompt, to have only sequence bookmarks as candidates.  And it's also trivial to define a command that jumps to only a bookmark of the new kind (restore a desktop and go to a location).]

Re: [External] : Re: A feature to go to last edit locations

[Jean Louis]

[-- Attachment #1: Type: text/plain, Size: 1889 bytes --]

* Dr. Arne Babenhauserheide <arne_bab@web.de> [2023-02-13 23:32]:
> With C-x r f <KEY> there’s something even more powerful: save the full
> frame configuration to a register (for example before starting a hunt
> towards some reference or investigating something in depth).

I need this. Back in time I have asked how can I capture that register
so that I can save it, and load it, eval it, to restore it. This is
for reason that I wish to capture it in the database.

I have tried this way:

(defun data-to-file (data file)
  "PRIN1 Emacs Lisp DATA to FILE"
  (string-to-file-force (prin1-to-string data) file))

(let ((hash (make-hash-table)))
  (data-to-file hash "~/my.hash")) ➜ "~/my.hash"

(defun data-from-file (file)
  "Reads and returns Emacs Lisp data from FILE"
  (condition-case nil
      (car (read-from-string
	    (file-to-string file)))
    (error nil)))

(let (hash)
  (setq hash (data-from-file "~/my.hash"))) ➜ #s(hash-table size 65 test eql rehash-size 1.5 rehash-threshold 0.8125 data ())

So that works for hash well.

But how do I save that window configuration register, so that I can load it?

Once I figure that out, I could quickly switch from this to that window configuration.

1. C-x r w 1 

2. (get-register ?1) ➜ (#<window-configuration> #<marker at 1208 in mutt-protected-1001-9339-1093665526192511358>)

3. (let ((window-configuration (get-register ?1)))
  (data-to-file window-configuration "~/my.register")) ➜ "~/my.register"

4. (data-from-file "~/my.register")
   car: Invalid read syntax: "#"

5. And there is no information of what is really window configuration

I wish to make it persistent, to be able to save it into file.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [External] : Re: A feature to go to last edit locations

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2023-02-13 22:49]:
> > Eli said something important, why go somewhere back randomly, but
> > better going where user marked it to need it.
>          ^^^^^^^^^^^^^^^^^^^^^^^
> > Now I get it with single click: S-C-<down> to record point and then
> > S-C-<left> and <right> to go to previous or next one.
> 
> You are reinventing (part of) what bookmarks do.

Ok, though is not bad, as I do not rely on Emacs Lisp, rather on
PostgreSQL. It could be re-written to use the now built-in SQLite.

> If you don't want to have to name bookmarks for this, then you can use autonamed bookmarks:
> https://www.emacswiki.org/emacs/BookmarkPlus#AutonamedBookmarks

I do not use names automatically, only with C-u prefix. All points are
automatically named. It is very easy to designate the record of the
point as one to be chosen by name or the one to be temporary (your
idea) or the one which was not named.

Only those named points should be used similarly as bookmarks.

> (Single key to set, single key to jump to.)
> 
> For that you need Bookmark+, but as an alternative you can just
> define a bookmark-setting command that provides default names of
> your own design.

Which single key?

I have to use complex key combinations, or maybe function keys.

> Rolling your own thingies which are essentially just bookmarks (and
> using a database to store them, no less) is really not necessary.

It makes things easy in my personal space. I can make package out of
it that uses SQLite. I use it in similar way as previous-buffer,
next-buffer, it is just more specific as by following Edi's advise to
mark what I want.

If necessary or not necesary, is personal opinion.

I am editing text objects in the database, and often temporary files. 

Standard bookmark does not work in a buffer without file. 

"Emacs points" that I have implemented work on temporary buffer.

Bookmark+ works on buffers without file.

"Emacs points" will self-destruct on non-existing buffers without
files:

2023-02-14-00:02:14 Self-destruction initiated on Emacs point ID 113 (reason: not found)

Bookmark+ gives error on buffers without file:

if: Jumping to bookmark: Cannot access file `   - no file -' or buffer `new' [2 times]

I am editing database text, my "Emacs points" can remember table,
column, table ID, to go back to the editing point (not fully
implemented, need few minutes).

No previous implementation can go to database backed text and point
inside.

Now you can see that it could be necessary, as not all cases are
covered.

And it has simple functionality that works already, due to database
usage. Just few functions on top of others. 

Imagine me dwelling in kilobytes of your code, I would never make it,
I feel discouraged and overwhelmed to understand it.

> It may be fun to do, but Emacs already has what you describe, as
> bookmarks.

Sure, though it is not same. 

I use these database backed Emacs places as "points" rather, to move
back and forth from point to point.

- Save point
- Toggle local (buffer based) movement or global movement
- Go next, previous or last, first

Names are automatically implemented, but user can name them explicitly
and so far I did not start using it by names. So it is not yet
"bookmark" in that sense, only point in buffer with or without file
name, or buffer editing database entry.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

RE: [External] : Re: A feature to go to last edit locations

[Drew Adams]

> > (Single key to set, single key to jump to.)
> 
> Which single key?  I have to use complex key
> combinations, or maybe function keys.

Setting an autonamed bookmark:

Command, `bmkp-toggle-autonamed-bookmark-set/delete'
sets or deletes an autonamed bookmark.  It does this:

  If there is an autonamed bookmark at point, delete it, else create one.
  The bookmark created has no region.  Its name is formatted according
  to option `bmkp-autoname-bookmark-function'.

  With a prefix arg, delete *ALL* autonamed bookmarks for this buffer.

Bind it to any key you like.  By default it's `RET' on
the `bookmark-map', which by default is on prefix key
`C-x x' -- so `C-x x RET'.

By default it's also `RET' on `bmkp-set-map', which by
default is on prefix key `C-x x c' (all commands that
set bookmarks are on this keymap).

Jumping to an autonamed bookmark:

Command `bmkp-autonamed-jump' jumps to an autonamed
bookmark.  By default it's `#' on `bmkp-jump-map',
which by default is on prefix key `C-x j'.

There's also `bmkp-this-buffer-jump' which jumps to
an autonamed bookmark in the current buffer.  By
default it's `C-x j , #'.

The jump commands prompt for an autonamed bookmark,
so they're not single-key in the same way that the
set/delete command is.  You generally don't want to
bind a key to just jump to a single bookmark (but
you can, of course).  Instead, you want to have a
key that jumps only to a bookmark of a given type
(in addition to a key that jumps to a bookmark of
any type).

_______

FYI, this is the automatic bookmarking doc string:

bmkp-automatic-bookmark-mode is an interactive Lisp function in
‘bookmark+-1.el’.

It is bound to menu-bar file bookmark options
bmkp-automatic-bookmark-mode.

(bmkp-automatic-bookmark-mode &optional ARG)

Toggle automatic setting of a bookmark when Emacs is idle.
Non-interactively, turn automatic bookmarking on for the current
buffer if and only if ARG is positive.

To enable or disable automatic bookmarking in all buffers, use
`bmkp-global-automatic-bookmark-mode'.

When the mode is enabled in the current buffer, a bookmark is
automatically set every `bmkp-automatic-bookmark-mode-delay' seconds,
using the setting function that is the value of option
`bmkp-automatic-bookmark-set-function'.  Note that a buffer must be
current (selected) for an automatic bookmark to be created there - it
is not enough that the mode be enabled in the buffer.

Turning the mode on and off runs hooks
`bmkp-automatic-bookmark-mode-on-hook' and
`bmkp-automatic-bookmark-mode-off-hook', respectively.

If you want the automatic bookmarks to be temporary (not saved to your
bookmark file), then customize option
`bmkp-autotemp-bookmark-predicates' so that it includes the kind of
bookmarks that are set by `bmkp-automatic-bookmark-set-function'.
For example, if automatic bookmarking sets autonamed bookmarks, then
`bmkp-autotemp-bookmark-predicates' should include
`bmkp-autonamed-bookmark-p' or
`bmkp-autonamed-this-buffer-bookmark-p'.

If you want the automatically created bookmarks to be highlighted,
then customize option `bmkp-auto-light-when-set' to highlight
bookmarks of the appropriate kind.  For example, to highlight
autonamed bookmarks set it to `autonamed-bookmark'.

Re: A feature to go to last edit locations

[Michael Welsh Duggan]

Daniel Martín <mardani29@yahoo.es> writes:

> Some IDEs and text editors provide a feature to go to the position of
> the last edit location across all buffers.  For example, in Eclipse or
> IntelliJ IDEA, this feature is under Navigate, Last Edit Location.  In
> Vim, this feature is called a "change list jump" [1], but it seems to
> work in a per-buffer basis.
>
> The closest thing in Emacs is pop-global-mark, but it's not quite the
> same feature. The global mark ring requires that the user sets the mark
> in advance, and most editing commands do not set the mark.  Information
> about last edit locations is already kept in buffer-undo-list, but this
> list is per-buffer and does not contain timestamps, so generating a
> "global" list for all buffers out of this data structure does not seem
> very possible or efficient at the moment; it may need a new data
> structure, perhaps at the C level.

I often want to jump to the last change I made in a buffer, but I've
never wanted this across buffers.  The method I use for this, burned
into my fingertips, is "C-_ C-SPC C-_", which is undo, set mark, undo.
The set-mark causes the second undo to redo and could be replaced by a
cursor movement instead, if one didn't want to mess up the mark
location.

So, although, once again, this doesn't work across buffers, using the
undo list might be helpful for coding such a feature.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: A feature to go to last edit locations

[Jean Louis]

* Michael Welsh Duggan <mwd@md5i.com> [2023-02-13 22:50]:
> I often want to jump to the last change I made in a buffer, but I've
> never wanted this across buffers.  The method I use for this, burned
> into my fingertips, is "C-_ C-SPC C-_", which is undo, set mark, undo.
> The set-mark causes the second undo to redo and could be replaced by a
> cursor movement instead, if one didn't want to mess up the mark
> location.

I got tired of it.

What I really need is quick conscious remembering, and then moving
back forth. Either in singler buffer, or across buffers. Very handy.

When I do C-SPC and C-u SPC then I can do similar, but is not
exhaustive.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: A feature to go to last edit locations

[Konstantin Kharlamov]

On Mon, 2023-02-13 at 14:49 -0500, Michael Welsh Duggan wrote:
> Daniel Martín <mardani29@yahoo.es> writes:
> 
> > Some IDEs and text editors provide a feature to go to the position of
> > the last edit location across all buffers.  For example, in Eclipse or
> > IntelliJ IDEA, this feature is under Navigate, Last Edit Location.  In
> > Vim, this feature is called a "change list jump" [1], but it seems to
> > work in a per-buffer basis.
> > 
> > The closest thing in Emacs is pop-global-mark, but it's not quite the
> > same feature. The global mark ring requires that the user sets the mark
> > in advance, and most editing commands do not set the mark.  Information
> > about last edit locations is already kept in buffer-undo-list, but this
> > list is per-buffer and does not contain timestamps, so generating a
> > "global" list for all buffers out of this data structure does not seem
> > very possible or efficient at the moment; it may need a new data
> > structure, perhaps at the C level.
> 
> I often want to jump to the last change I made in a buffer, but I've
> never wanted this across buffers.  The method I use for this, burned
> into my fingertips, is "C-_ C-SPC C-_", which is undo, set mark, undo.
> The set-mark causes the second undo to redo and could be replaced by a
> cursor movement instead, if one didn't want to mess up the mark
> location.
> 
> So, although, once again, this doesn't work across buffers, using the
> undo list might be helpful for coding such a feature.

For buffer-local case I know at least one implementation that I use daily: in
Evil mode the `g;` combination. There may be others probably.

Global case though isn't covered AFAIK.

Re: A feature to go to last edit locations

[Ergus]

On February 13, 2023 8:49:46 PM GMT+01:00, Michael Welsh Duggan <mwd@md5i.com> wrote:
>Daniel Martín <mardani29@yahoo.es> writes:
>
>> Some IDEs and text editors provide a feature to go to the position of
>> the last edit location across all buffers.  For example, in Eclipse or
>> IntelliJ IDEA, this feature is under Navigate, Last Edit Location.  In
>> Vim, this feature is called a "change list jump" [1], but it seems to
>> work in a per-buffer basis.
>>
>> The closest thing in Emacs is pop-global-mark, but it's not quite the
>> same feature. The global mark ring requires that the user sets the mark
>> in advance, and most editing commands do not set the mark.  Information
>> about last edit locations is already kept in buffer-undo-list, but this
>> list is per-buffer and does not contain timestamps, so generating a
>> "global" list for all buffers out of this data structure does not seem
>> very possible or efficient at the moment; it may need a new data
>> structure, perhaps at the C level.
>
>I often want to jump to the last change I made in a buffer, but I've
>never wanted this across buffers.  The method I use for this, burned
>into my fingertips, is "C-_ C-SPC C-_", which is undo, set mark, undo.

I use exactly this same method (undo-redo). It is not very confortable, so any function to mimic part of this may be useful... But please, nothing that affects performance creating fancy cache features. I am having enough issues with performance already...


>The set-mark causes the second undo to redo and could be replaced by a
>cursor movement instead, if one didn't want to mess up the mark
>location.
>
>So, although, once again, this doesn't work across buffers, using the
>undo list might be helpful for coding such a feature.
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: A feature to go to last edit locations

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]


Ergus <spacibba@aol.com> writes:

> On February 13, 2023 8:49:46 PM GMT+01:00, Michael Welsh Duggan <mwd@md5i.com> wrote:
>>Daniel Martín <mardani29@yahoo.es> writes:
>>
>>> Some IDEs and text editors provide a feature to go to the position of
>>> the last edit location across all buffers.  For example, in Eclipse or
>>> IntelliJ IDEA, this feature is under Navigate, Last Edit Location.  In
>>> Vim, this feature is called a "change list jump" [1], but it seems to
>>> work in a per-buffer basis.
>>>
>>> The closest thing in Emacs is pop-global-mark, but it's not quite the
>>> same feature. The global mark ring requires that the user sets the mark
>>> in advance, and most editing commands do not set the mark.  Information
>>> about last edit locations is already kept in buffer-undo-list, but this
>>> list is per-buffer and does not contain timestamps, so generating a
>>> "global" list for all buffers out of this data structure does not seem
>>> very possible or efficient at the moment; it may need a new data
>>> structure, perhaps at the C level.
>>
>>I often want to jump to the last change I made in a buffer, but I've
>>never wanted this across buffers.  The method I use for this, burned
>>into my fingertips, is "C-_ C-SPC C-_", which is undo, set mark, undo.
>
> I use exactly this same method (undo-redo). It is not very
> confortable, so any function to mimic part of this may be useful...

Try the goto-chg package. It just uses the undo ring to find previous
locations. Sometime it’s a bit buggy when you use lsps with save
actions, but in general it works really well.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: A feature to go to last edit locations

[Karthik Chikmagalur]

> Try the goto-chg package. It just uses the undo ring to find previous
> locations. Sometime it’s a bit buggy when you use lsps with save
> actions, but in general it works really well.

I would like to second this.  goto-chg is much more reliable for me as a
jump command compared to pop-mark (C-u C-SPC).  The common use-case is
when I'm editing text and jump away to examine or copy text from a
different part of the buffer.  Since many motion commands set the mark,
it can take several invocations of pop-mark to get back to where I was
editing, sometimes a double digit number.  In comparison,
goto-last-change reliably brings me back immediately to where I was
typing.  I do this often enough (sometimes several times a minute) that
setting a register each time before jumping is infeasible.

The fact that it reuses undo information means there's no perceptible
performance penalty either.

Karthik