4:37 p.m.
Hello
Does anybody know about a package which would allow to
annote the changes but set a mark, such that later I could navigate to
that part of the buffer where the change occurred. Bm.el or bookmark.el
would be candidates, but they are not connected to change-log
Example
Original file
Hello world.
This is a great idea.
Changed to
Hello world.
This is a good idea.
Change log entry would be
2006-11-16 Uwe Brauer <oub(a)mat.ucm.es>
* test: Change great to good.
Setting the mouse say on test, and using a modified ffap-guesser
XEmacs would jump where the change occurred. In order to do this at
least the char-number should be stored, best would be a string before
and after the change in order to simplify the search. Bm.el and
bookmarks.el do this.
Thanks and regards
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:31 a.m.
Uwe Brauer writes:
Does anybody know about a package which would allow to
annote the changes but set a mark, such that later I could navigate to
that part of the buffer where the change occurred. Bm.el or bookmark.el
would be candidates, but they are not connected to change-log
Have you looked at hyperbole?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:07 p.m.
>>>> Stephen J<stephen(a)xemacs.org> writes:
Stephen> Uwe Brauer writes:
> Does anybody know about a package which would allow to
> annote the changes but set a mark, such that later I could navigate to
> that part of the buffer where the change occurred. Bm.el or bookmark.el
> would be candidates, but they are not connected to change-log
Stephen> Have you looked at hyperbole?
Unfortunately there is no such thing in hyperbole, yet.
Triggered by this request I did some experiment, added an implicit
change-log-mode button and tried to think about what could be
done.
* What comes first in mind is trying to come up with an implicit
button.
The file name from the ChangeLog is easy to use but will bring you
only to the file. Which could be desirable but is not what is
requested.
Using the function, variable or whatever string between the parenthesis:
" * filename (<interesting string>): ...
could also be done. The "search" for the <interesting string> could
be sequential or could be an input for a tags-search limited to the
filename. It could also consult functions, imenu or maybe even tried
as a bookmark in order to find a suitable cross reference.
It all seems to get a bit complicated without really solving the
requested functionality.
* Creating an explicit button in the ChangeLog is not desirable I
think!? (Excplicit means that an hyperbole button "<....>" is
inserted. The link will be persistent but the ChangeLog will contain
hyperbole buttons ...)
* What I think really is wanted is that a cross reference is created
from the ChangeLog to from where add-change-log-entry was
invoked. This should all take place behind the scene so that when
clicking on that line in the ChangeLog you will be transfered back
to where it all began.
From a quick look at bm.el it doesn't seem to implement this but
rather create a visible bookmark to which you can jump from the
bookmarks associated with that file.
Maybe that idea could be taken further and any line in a buffer
could be the starting point for a cross reference to a position in
another file. Then a modified add-change-log-entry could update that
cross reference. However this transfers the problem into how to
update the cross reference when the originating file is changed
which doesn't seem to be trivial.
Ideas!?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
3:58 p.m.
>>>> "Mats" == Mats Lidell
<matsl(a)xemacs.org> writes:
Stephen> Have you looked at hyperbole?
Mats> Unfortunately there is no such thing in hyperbole, yet.
Mats> Triggered by this request I did some experiment, added an
Mats> implicit change-log-mode button and tried to think about what
Mats> could be done.
Mats> * What comes first in mind is trying to come up with an implicit
Mats> button.
Mats> It all seems to get a bit complicated without really solving the
Mats> requested functionality.
Mats> * Creating an explicit button in the ChangeLog is not desirable I
Mats> think!? (Excplicit means that an hyperbole button "<....>"
Mats> is inserted. The link will be persistent but the ChangeLog
Mats> will contain hyperbole buttons ...)
Well I would not mind, if it where easy to create and to use.
But of course as you said, I would like that when I run the modified
add-change-log-entry, then the position of the change is stored and
the link is set automatically.
Mats> * What I think really is wanted is that a cross reference is created
Mats> from the ChangeLog to from where add-change-log-entry was
Mats> invoked. This should all take place behind the scene so
Mats> that when clicking on that line in the ChangeLog you will
Mats> be transfered back to where it all began.
Mats> From a quick look at bm.el it doesn't seem to implement
Mats> this but rather create a visible bookmark to which you can
Mats> jump from the bookmarks associated with that file.
Right
Mats> Maybe that idea could be taken further and any line in a
Mats> buffer could be the starting point for a cross reference to
Mats> a position in another file. Then a modified
Mats> add-change-log-entry could update that cross
Mats> reference. However this transfers the problem into how to
Mats> update the cross reference when the originating file is
Mats> changed which doesn't seem to be trivial.
Right, this a problem in bm and in bookmark.el. However bookmark has a
clever idea (which was then implemented by bm as well): not only store
the char position, where the change occurred, but store also some
strings before and after the change (this is called front-context-string and
rear-context-string) in order take into account a possible change of
the file later.
Example ^ indicates where the change occurs
,----
| This is a line
| here I will change tis
| ^
| another line.
`----
Then the cursor position
- ^ is stored together with the strings
- "change" and
- "another"
Then when I make changes of the form
,----
| a new line
| This is a line
| here I will change tis
| ^
| another line.
`----
Then everything is fine and the ^ can be found.
The question reminds were to store all that information. I see three
possibilities:
- In the change log file (but may be in the non visible
part). However that might be complicated
- In a global file in the home directory
- In a file associated which every changelog file
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:52 a.m.
Uwe Brauer writes:
>>>>> "Mats" == Mats Lidell
<matsl(a)xemacs.org> writes:
Mats> * Creating an explicit button in the ChangeLog is not
desirable I
Mats> think!? (Excplicit means that an hyperbole button "<....>"
Mats> is inserted. The link will be persistent but the ChangeLog
Mats> will contain hyperbole buttons ...)
Well I would not mind, if it where easy to create and to use.
But of course as you said, I would like that when I run the modified
add-change-log-entry, then the position of the change is stored and
the link is set automatically.
OK, Hyperbole doesn't seem to do what you want.
Mats> * What I think really is wanted is that a cross reference
is created
Mats> from the ChangeLog to from where add-change-log-entry was
Mats> invoked.
[...]
Mats> Maybe that idea could be taken further and any line in
a
Mats> buffer could be the starting point for a cross reference to
Mats> a position in another file. Then a modified
Mats> add-change-log-entry could update that cross
Mats> reference. However this transfers the problem into how to
Mats> update the cross reference when the originating file is
Mats> changed which doesn't seem to be trivial.
Right, this a problem in bm and in bookmark.el. However bookmark has a
clever idea (which was then implemented by bm as well): not only store
the char position, where the change occurred, but store also some
strings before and after the change (this is called front-context-string and
rear-context-string) in order take into account a possible change of
the file later.
The question reminds were to store all that information. I see three
possibilities:
- In the change log file (but may be in the non visible
part). However that might be complicated
I don't think this is very desirable. These bookmarks seem likely to
become numerous but also to get stale rapidly.
- In a global file in the home directory
- In a file associated which every changelog file
Which of these does bookmark do? I would lean toward the global file,
but it's probably easiest to use bookmark's features. If you use
add-change-log-entry (and friends), then I would say that an around
advice that first creates a bookmark at the change point, then
executes the original function, then creates a bookmark in the
ChangeLog, and finally links each bookmark to the other, might be the
way to go. The links might be kept in a separate file from the
bookmarks file.
In the long run you'd probably want to revise bookmark to allow links
in any bookmark rather than having a separate file of links, but I'm
not even sure of that.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
3:47 p.m.
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Stephen> Uwe Brauer writes:
> Does anybody know about a package which would allow to
> annote the changes but set a mark, such that later I could navigate to
> that part of the buffer where the change occurred. Bm.el or bookmark.el
> would be candidates, but they are not connected to change-log
Stephen> Have you looked at hyperbole?
Well I tried it from time to time, it looks complicated though very
complete.
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6571
days inactive
6575
days old
5 comments
3 participants
participants (3)
-
Stephen J. Turnbull -
The XEmacs Package Smoketest -
Uwe Brauer