Re: [ jEdit-users ] Adding a marker shouldn't mark buffer as "modified"

[Slava P. <sl...@je...>]

Hi,

Thanks for the suggestions, I will keep them in mind for the future.

On Sat, 2003-11-01 at 11:22, Michael Henry wrote:
> Slava Pestov wrote:
> 
>  >I agree with the ideas in your post. However, storing markers in
>  >~/.jedit/markers/ or something might be problematic too. First of all,
>  >the directory will get cluttered if files are deleted outside of jEdit;
>  >also how will the files therein be named? If each one has eg a random
>  >number as a name, then a mapping of path -> marker file will have to be
>  >loaded; this mapping might get large. Alternatively a hash code can be
>  >used, but this might have other problems...
> 
> Before I discovered jEdit, I did almost all my text editing under
> Windows using CodeWright. Bookmark support in CodeWright is extensive
> and convenient. Here are some of the features of CodeWright bookmarks:
> 
> - Bookmarks are either local or global. Local bookmarks are like
>   jEdit's markers, in that they are scoped to the current buffer.
>   Global bookmarks apply across buffers. The Go To Bookmark operation
>   will first switch to the proper buffer for the global bookmark. Note
>   that the target file must be open in a buffer for this to work.
>   Global bookmarks are very convenient, and are the default kind of
>   bookmark in CodeWright.
>  
> - Bookmarks are numbered, and optionally named as well. The Go To
>   Bookmark command accepts either a number or a name as the target.
>  
> - Bookmarks have icons in the gutter to indicate their position (like
>   in jEdit). The first nine bookmarks have their number as part of the
>   icon, which is a convenient touch.
> 
> - Bookmarks may optionally be stored in a project file. With this
>   method, only bookmarks for open files are stored. When a file is
>   closed, its bookmarks are removed. This keeps the storage
>   requirements down and keeps old junk from accumulating, while
>   allowing different sets of bookmarks to be kept on a per-project
>   basis for "active" files, which are files that are still open in
>   your workspace.
>  
> - Bookmarks may optionally be stored in a global database. In this
>   case, the bookmarks persist even if the files are closed (similar to
>   the jEdit semantic for stored bookmarks). Options are provided for
>   allowing this database to grow without bound, or to remove entries
>   more than a specified number of days old. A dialog box permits
>   browsing and manual maintenance of the database if desired.
>  
> In practice, I tend to use CodeWright's first nine global bookmarks
> for fast navigation during an editing session. I just drop bookmark #1
> somewhere, run off to another file and copy some text, jump back to
> bookmark #1 in my original file and I'm done. Occasionally I might
> leave bookmark #2 in that second file, or I might need to perform some
> sub-task before returning. For these tasks, the global nature of the
> bookmarks is very handy, as I can return to my place even if it is in
> another file. Generally, I find it sufficient to retain these
> bookmarks (if at all) only while the files are open, so storing them
> in the project file is fine.
> 
> For longer-term bookmarking, named bookmarks are more appropriate as
> it is harder to remember bookmark numbers. With my editing style, I
> don't give names to bookmarks, although I know that some people use
> bookmarks with names like "last" for marking where they should resume.
> I tend to let the caret position be my guide for where I left off.
> 
> In jEdit, I like the Go To Previous/Next Marker capability, and I like
> having single-character shortcuts for markers. I would really like to
> see global markers that would take me across buffers, for which
> feature I'd give up marker persistence completely :-) Personally, I'd
> also give up local markers, but I can't speak for others who might
> really like the local marker concept.
> 
> I wonder if the persistence of markers could be separated out from the
> logic for setting and jumping to markers in the core. The jEdit core
> would track changes in marker status separately from changes to buffer
> contents. When a file is to be closed, jEdit could signal some kind of
> SAVE_MARKERS event, and just after a file has been opened, jEdit could
> signal a LOAD_MARKERS event. A marker API could be exposed by the core
> for plugins to perform some of these functions:
> 
> setMarkers(buffer, markers) // use listOfMarkers for buffer's markers
> getMarkers(buffer)          // returns all markers in this buffer
> 
> I'm sure it's clear that I have no real idea how the jEdit core works,
> so this idea may be laughable - I'm just thinking out loud. A plugin
> responsible for marker persistence would then use this API to save off
> the markers however it wanted. The Project Viewer plugin, or perhaps
> the Sessions plugin, could subscribe to such events and handle
> persistence on a per-project or per-session basis. If someone wanted
> markers to persist after the file is closed (i.e., no longer part of
> the session), another plugin could be written to save off the markers
> in a global database (as CodeWright does), and to prune the database
> by marker age in days, or by keeping only the N most-recently-used
> markers in the database, or whatever.
> 
> The nice thing about separating out the persistence feature is that
> it paves the way for plugin authors to come up with fancier ways
> of persisting markers, but in the meantime the current .marks file
> method could be separated into a standard plugin.
> 
> Michael Henry
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
-- 
Slava Pestov