Seeking advice on writing a "line-based" major mode

Seeking advice on writing a "line-based" major mode

[Marcin Borkowski]

Hi all,

I'm going to start coding a major mode, a bit like dired or grep-mode or
org-agenda mode, in which the buffer will contain a bunch of lines, each
of them correspoding to some object (basically, I have a vector of these
"objects", and I want to display them in some way).

This raises two problems.

1. I want to be able to display these objects using some kind of
a "template" (not unlike org's "property table", or dired's format
etc.).  I'd like this "template" to be configurable using a user option
(with possibilities like "x characters for a name, then y characters for
description, etc. for other fields").

2. When the point is one one of these lines, I want various keybindings
to perform some actions on the object in question (like, again, in
Dired or org-agenda).

Is there anything in Emacs or its libraries which might help with these
tasks?  For instance, each "object" is identified by a name (it's the
"primary key", so to speak), but it need not be e.g. the first thing on
the line.  The displaying function could use text properties of the
particular lines so that Emacs knows which object to act upon when point
is in some place, but maybe there is a ready-made library for that?

And maybe there is even a more general library to establish
a correspondence between some vector/list of objects and a buffer whose
lines contain some textual representation of these objects, so that
I wouldn't have to code e.g. the displaying routine from scratch?

Of course I could code all that myself - it doesn't seem to be too much
work - but why reinvent the wheel?

TIA,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

RE: Seeking advice on writing a "line-based" major mode

[Drew Adams]

> the buffer will contain a bunch of lines, each of them
> correspoding to some object (basically, I have a vector
> of these "objects", and I want to display them in some way).

Sounds like a candidate for `tabulated-list-mode'.  You can
use that to print lines that are composed of one or more
columns, and a header line that let you sort by any column
(if you want).

> 1. I want to be able to display these objects using some kind of
> a "template" (not unlike org's "property table", or dired's format
> etc.).  I'd like this "template" to be configurable using a user
> option (with possibilities like "x characters for a name, then y
> characters for description, etc. for other fields").

That sounds like exactly what `tabulated-list.el' lets you do.
See (buffer-local) variable `tabulated-list-format'.

> 2. When the point is one one of these lines, I want various
> keybindings to perform some actions on the object in question
> (like, again, in Dired or org-agenda).

By default, RET on an entry in the table (i.e., in a given row
and column) just sorts that column.  But you can bind it to do
anything you like.

You might take a look at my library apu.el, which uses t-l-mode
this way.  The info in each row of the table is info about a
given Unicode char.  When you hit RET anywhere in that row a
buffer pops up with more complete info about that char.  Various
keys perform other actions on the given char.
http://www.emacswiki.org/emacs/apu.el (I haven't yet put it on
MELPA.)

> Is there anything in Emacs or its libraries which might help with
> these tasks?  For instance, each "object" is identified by a name
> (it's the "primary key", so to speak), but it need not be e.g.
> the first thing on the line.

Same thing with t-l-mode.

> The displaying function could use text properties of the
> particular lines so that Emacs knows which object to act
> upon when point is in some place, but maybe there is a
> ready-made library for that?

You can use text properties that way with t-l-mode, but you
should not need to.

> And maybe there is even a more general library to establish
> a correspondence between some vector/list of objects and a buffer
> whose lines contain some textual representation of these objects,
> so that I wouldn't have to code e.g. the displaying routine from
> scratch?

Again, that description sounds just like t-l-mode.

> Of course I could code all that myself - it doesn't seem to be too
> much work - but why reinvent the wheel?

Right.

[BTW, I would recommend against looking to things like Dired as
examples for this kind of thing.  Dired is very complex and does
lots of things in special ways.  And its code has evolved
organically, so to speak. ;-)  It is not something simple like what
you describe.  Look instead to things like buff-menu.el (which now
uses t-l-mode) and `list-faces-display' and `list-colors-display'.

Re: Seeking advice on writing a "line-based" major mode

[Marcin Borkowski]

On 2015-06-08, at 04:17, Drew Adams <drew.adams@oracle.com> wrote:

>> the buffer will contain a bunch of lines, each of them
>> correspoding to some object (basically, I have a vector
>> of these "objects", and I want to display them in some way).
>
> Sounds like a candidate for `tabulated-list-mode'.  You can
> use that to print lines that are composed of one or more
> columns, and a header line that let you sort by any column
> (if you want).

Thanks for your tip, though after consideration I ended up using EWOC.

> [BTW, I would recommend against looking to things like Dired as
> examples for this kind of thing.  Dired is very complex and does
> lots of things in special ways.  And its code has evolved
> organically, so to speak. ;-)  It is not something simple like what
> you describe.  Look instead to things like buff-menu.el (which now
> uses t-l-mode) and `list-faces-display' and `list-colors-display'.

Fair enough.  I was mentioning Dired more to convey my needs than as
a suggestion that I'd like to mimick its implementation - it is far more
complex than what I need.

Regards,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

RE: Seeking advice on writing a "line-based" major mode

[Drew Adams]

> >> the buffer will contain a bunch of lines, each of them
> >> correspoding to some object (basically, I have a vector
> >> of these "objects", and I want to display them in some way).
> >
> > Sounds like a candidate for `tabulated-list-mode'.  You can
> > use that to print lines that are composed of one or more
> > columns, and a header line that let you sort by any column
> > (if you want).
> 
> Thanks for your tip, though after consideration I ended up using
> EWOC.

It might help others if you say why.  For example, what in your
problem context helped you decide that EWOC might be more useful
to it than `tabulated-list-mode'?

Re: Seeking advice on writing a "line-based" major mode

[Marcin Borkowski]

On 2015-06-18, at 18:10, Drew Adams <drew.adams@oracle.com> wrote:

>> >> the buffer will contain a bunch of lines, each of them
>> >> correspoding to some object (basically, I have a vector
>> >> of these "objects", and I want to display them in some way).
>> >
>> > Sounds like a candidate for `tabulated-list-mode'.  You can
>> > use that to print lines that are composed of one or more
>> > columns, and a header line that let you sort by any column
>> > (if you want).
>> 
>> Thanks for your tip, though after consideration I ended up using
>> EWOC.
>
> It might help others if you say why.  For example, what in your
> problem context helped you decide that EWOC might be more useful
> to it than `tabulated-list-mode'?

Good point.

1. EWOC has built-in support for checking which entry the point is on.
I didn't find anything like that in tabulated-list-mode.

2. EWOC seems to be more flexible wrt the format of the entries.  In my
use case, each entry is a large-ish alist, converted from json by
json-read, and most of the entries in it should not show up at all.

OTOH, t-l-m has some things that EWOC doesn't:

1. Automatic sorting, though this is not that difficult to achieve in
EWOC, too.  (Also, what I need is a few more complicated sorting
algorithms - for instance, one of the columns is a timestamp, and I want
to be able to sort by time *or* by time of the day alone, disregarding
the date; I's also want to be able to do sorting based on more than one
column etc.)

2. A major mode to derive from - with EWOC, I'll probably end up
deriving my mode from special-mode.

So basically, while the differences are significant, both tools could do
the job - it just happens that EWOC has the parts I didn't want to code
myself already done.  As Emanuel points out, I could even do everything
myself from scratch.

BTW, be assured that when I finish my tool (or at least get to
a production-ready beta, which seems quite close), I'll write a blog
post (or a few) about it, and put the code on the net somewhere.  (I
won't write about it here too much, though, since it is a client for
a cloudy-ish service on the net which is not "free as in beer" and uses
software which is not "free as in FSF".  Moreover, the nature of the
service seems to almost *exclude* the possibility of a free version, at
least in the "as in beer" sense - "free as in FSF" might be
theoretically possible, though maybe unreasonable from business
standpoint - I see no much point in giving away server-side software
which is a basis for your rather niche business.)

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

RE: Seeking advice on writing a "line-based" major mode

[Drew Adams]

Thanks for providing more info.

> 1. EWOC has built-in support for checking which entry the point is
> on. I didn't find anything like that in tabulated-list-mode.

Not sure what you mean, but that sounds like `tabulated-list-get-entry':

  Return the Tabulated List entry at POS. ... defaults to point.

or depending on what you mean, perhaps `tabulated-list-get-id':

  Return the entry ID of the Tabulated List entry at POS.
  ... defaults to point.

> 2. EWOC seems to be more flexible wrt the format of the entries.  In
> my use case, each entry is a large-ish alist, converted from json by
> json-read, and most of the entries in it should not show up at all.

So you want to show only some of each alist entry.

  `tabulated-list-print' calls the printer function specified by
  `tabulated-list-printer', once for each entry.  The default
  printer is `tabulated-list-print-entry', but a mode that keeps
  data in an ewoc may instead specify a printer function (e.g., one
  that calls `ewoc-enter-last'), with `tabulated-list-print-entry'
  as the ewoc pretty-printer.

and `tabulated-list-entries':

  If a list, each element has the form (ID [DESC1 ... DESCN])
  
or it can be a function that returns such a list.

In your case, one of the DESC would presumably be your alist value,
formatted to show only some of it.

I know very little about EWOC, but so far I don't really see what
more it offers here.  (Not that I need to.  The info you provide is
anyway helpful.) 

> I's also want to be able to do sorting based on more than one
> column

Same here.  That would be a useful addition to `tabulated-list-mode'.

> So basically, while the differences are significant, both tools
> could do the job - it just happens that EWOC has the parts I didn't
> want to code myself already done.

Understood (though it's not clear to me what those parts are).

> BTW, be assured that when I finish my tool (or at least get to
> a production-ready beta, which seems quite close), I'll write a blog
> post (or a few) about it, and put the code on the net somewhere.

Thx. 

Re: Seeking advice on writing a "line-based" major mode

[Marcin Borkowski]

On 2015-06-18, at 21:50, Drew Adams <drew.adams@oracle.com> wrote:

> Thanks for providing more info.
>
>> 1. EWOC has built-in support for checking which entry the point is
>> on. I didn't find anything like that in tabulated-list-mode.
>
> Not sure what you mean, but that sounds like `tabulated-list-get-entry':
>
>   Return the Tabulated List entry at POS. ... defaults to point.
>
> or depending on what you mean, perhaps `tabulated-list-get-id':
>
>   Return the entry ID of the Tabulated List entry at POS.
>   ... defaults to point.

Cool.  Neither is mentioned in the Info manual, though...

>> 2. EWOC seems to be more flexible wrt the format of the entries.  In
>> my use case, each entry is a large-ish alist, converted from json by
>> json-read, and most of the entries in it should not show up at all.
>
> So you want to show only some of each alist entry.
>
>   `tabulated-list-print' calls the printer function specified by
>   `tabulated-list-printer', once for each entry.  The default
>   printer is `tabulated-list-print-entry', but a mode that keeps
>   data in an ewoc may instead specify a printer function (e.g., one
>   that calls `ewoc-enter-last'), with `tabulated-list-print-entry'
>   as the ewoc pretty-printer.
>
> and `tabulated-list-entries':
>
>   If a list, each element has the form (ID [DESC1 ... DESCN])
>   
> or it can be a function that returns such a list.
>
> In your case, one of the DESC would presumably be your alist value,
> formatted to show only some of it.
>
> I know very little about EWOC, but so far I don't really see what
> more it offers here.  (Not that I need to.  The info you provide is
> anyway helpful.) 

So it seems that the main advantage of EWOC is better (i.e., more
comprehensive) manual...

>> I's also want to be able to do sorting based on more than one
>> column
>
> Same here.  That would be a useful addition to `tabulated-list-mode'.
>
>> So basically, while the differences are significant, both tools
>> could do the job - it just happens that EWOC has the parts I didn't
>> want to code myself already done.
>
> Understood (though it's not clear to me what those parts are).

Maily the get-item-at-point, which t-l-m seems to have, too...  Also,
the sorting stuff, though this is not really relevant: I presume that
with t-l-m, I could do sorting "manually", i.e., on the underlying data
structure.

All in all, it seems that (apart from the manual) EWOC has only one
advantage for me: I already have some working code using it...

>> BTW, be assured that when I finish my tool (or at least get to
>> a production-ready beta, which seems quite close), I'll write a blog
>> post (or a few) about it, and put the code on the net somewhere.
>
> Thx. 

You're welcome, though it will take some time (I'm going for a vacation
in a few days).

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

RE: Seeking advice on writing a "line-based" major mode

[Drew Adams]

> > `tabulated-list-get-entry':
> >   Return the Tabulated List entry at POS...
> > `tabulated-list-get-id':
> >   Return the entry ID of the Tabulated List entry at POS...
> 
> Cool.  Neither is mentioned in the Info manual, though...

If you think it is important/useful, consider filing a doc bug:
`M-x report-emacs-bug'.

> So it seems that the main advantage of EWOC is better (i.e., more
> comprehensive) manual...

If you think so: `M-x report-emacs-bug'.

> >> EWOC has the parts I didn't want to code myself already done.
> > Understood (though it's not clear to me what those parts are).
> 
> Maily the get-item-at-point, which t-l-m seems to have, too...
> Also, the sorting stuff, though this is not really relevant: I presume
> that with t-l-m, I could do sorting "manually", i.e., on the underlying
> data structure.

Yes, you can sort the data any way you like.  You can associate different
sorts with different columns, so that when you hit return with point in a
given column a given sort predicate is used.

The SORT value specified in `tabulated-list-format' for each column: 

 - SORT specifies how to sort entries by this column.
   If nil, this column cannot be used for sorting.
   If t, sort by comparing the string value printed in the column.
   Otherwise, it should be a predicate function suitable for
   `sort', accepting arguments with the same form as the elements
   of `tabulated-list-entries'.

What is passed to the sort function to compare are two rows of the
table (not as displayed, but the underlying data), i.e., "elements
of `tabulated-list-entries'".

> All in all, it seems that (apart from the manual) EWOC has only one
> advantage for me: I already have some working code using it...

;-)  It may have other advantages too; dunno.

Re: Seeking advice on writing a "line-based" major mode

[Marcin Borkowski]

On 2015-06-18, at 21:50, Drew Adams <drew.adams@oracle.com> wrote:

>> So basically, while the differences are significant, both tools
>> could do the job - it just happens that EWOC has the parts I didn't
>> want to code myself already done.
>
> Understood (though it's not clear to me what those parts are).
>
>> BTW, be assured that when I finish my tool (or at least get to
>> a production-ready beta, which seems quite close), I'll write a blog
>> post (or a few) about it, and put the code on the net somewhere.
>
> Thx. 

OK, so the blog post is online:
http://mbork.pl/2015-07-18_TLM_vs_EWOC%2c_or_there_and_back_again
(There are some problems with the styling on my site, but I don't have
time to fix that now, sorry.)

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Seeking advice on writing a "line-based" major mode

[Robert Thorpe]

Marcin Borkowski <mbork@mbork.pl> writes:
...
>
> OK, so the blog post is online:
> http://mbork.pl/2015-07-18_TLM_vs_EWOC%2c_or_there_and_back_again
> (There are some problems with the styling on my site, but I don't have
> time to fix that now, sorry.)

That's useful to me.  I'm planning to write a mode using one of those
two libraries in a few months time.

Thanks,
Robert Thorpe

Re: Seeking advice on writing a "line-based" major mode

[Emanuel Berg]

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

>> Thanks for your tip, though after consideration
>> I ended up using EWOC.
>
> It might help others if you say why. For example,
> what in your problem context helped you decide that
> EWOC might be more useful to it than
> `tabulated-list-mode'?

Otherwise it'll be like Napoleon before marching into
the Russian Empire: "You start it, then you see
what happens."

:)

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Seeking advice on writing a "line-based" major mode

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> Fair enough. I was mentioning Dired more to convey
> my needs than as a suggestion that I'd like to
> mimick its implementation - it is far more complex
> than what I need.

I think there are two schools how to do this.

The easiest way and the way I would do it is to just
write an iteration (or recursive) algorithm to
populate the window with data, which will also serve
as the UI.

Simply have a key (e.g., RET) execute an algorithm to
act on the data:

    (let ((data (thing-at-point ... )))
      (if ( ... data) (action data) ... ))

Last do polishing: font-lock keywords,
(speedified) cursor-movements, etc.

The more advanced way which is more schoolbookish and
ultimately more powerful (but it depends on the
purpose if such power is needed) is to have the UI
window-dressing separated from the logic - which you
instead put in text properties.

Then you can even have the UI format-stringed and have
the user curtain it in whatever way desired, but the
functionality will remain untouched.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Seeking advice on writing a "line-based" major mode

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> I think there are two schools how to do this.
>
> The easiest way and the way I would do it is to just
> write an iteration (or recursive) algorithm to
> populate the window with data, which will also serve
> as the UI.
>
> Simply have a key (e.g., RET) execute an algorithm to
> act on the data:
>
>     (let ((data (thing-at-point ... ))) (if ( ...
> data) (action data) ... ))

Here is an example of this method - or check out the
file here:

    http://user.it.uu.se/~embe8573/line-file-table.el

See that last comment block for how to invoke AND an
interesting thing with point position that differs in
byte-compiled vs. normal mode.

(defun find-file-at-line (&optional other-window)
  (interactive "P")
  (let ((possible-filename (thing-at-point 'filename))
        (find-f (if other-window 'find-file-other-window 'find-file)) )
    (if (and possible-filename (file-exists-p possible-filename))
          (apply find-f `(,possible-filename))
      (progn
        (forward-char 1)
        (find-file-at-line) ))))

(defvar *files* '("~/.emacs" "~/.gnus" "~/.zshrc" "~/.zshenv"))

(defun make-table ()
    (insert ";; Either press M-RET or M-r to visit a file.\n"
            ";; If a file doesn't exist, the next one is tried.\n;;\n" )
    (save-excursion ; [1]
      (dolist (f *files*)
        (insert (format ";; %s\n" f)) )))

(local-set-key "\M-\r" 'find-file-at-line) ; M-RET
(local-set-key "\M-r"  'find-file-at-line) ; M-r

(make-table)

;; [1] for whatever reason (?) this isn't applied with
;;
;;         emacs -Q -l ~/line-file-table.el
;;
;;     but if compiled first
;;
;;         emacs --batch -f batch-byte-compile ~/line-file-table.el;
;;         emacs -Q -l ~/line-file-table.elc
;;
;;     then it works.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Seeking advice on writing a "line-based" major mode

[Emanuel Berg]

Here is a hybrid: buttons, but data as the button
labels - that's clever, ey?

(defun find-file-button-f (button)
  (find-file (button-label button)) )

(define-button-type 'find-file-button
  'action 'find-file-button-f
  'follow-link t)

(defvar *files* '("~/.emacs" "~/.gnus" "~/.zshrc" "~/.zshenv"))

(insert "Hit RET on these buttons to visit the file.\n"
        "If there isn't such a file, open an empty buffer with that name.\n\n")

(save-excursion ; doesn't work if not compiled (see last comment)
  (dolist (f *files*)
    (insert-text-button f :type 'find-file-button)
    (insert "\n") ))

;; execute:
;;
;;    emacs -Q -l button.el
;;
;; or:
;;
;;    emacs --batch -f batch-byte-compile button.el
;;    emacs -Q -l button.elc

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Seeking advice on writing a "line-based" major mode

[Tom Tromey]

Marcin> I'm going to start coding a major mode, a bit like dired or grep-mode or
Marcin> org-agenda mode, in which the buffer will contain a bunch of lines, each
Marcin> of them correspoding to some object (basically, I have a vector of these
Marcin> "objects", and I want to display them in some way).

People have already mentioned tabulated-list-mode.

Another way to go is EWOC, also part of the Emacs core.
EWOC is used at least by vc-dir but also I think some other modes.

I would suggest using whichever one fits your needs best.

Tom

Re: Seeking advice on writing a "line-based" major mode

[Marcin Borkowski]

On 2015-06-08, at 15:37, Tom Tromey <tom@tromey.com> wrote:

> Marcin> I'm going to start coding a major mode, a bit like dired or grep-mode or
> Marcin> org-agenda mode, in which the buffer will contain a bunch of lines, each
> Marcin> of them correspoding to some object (basically, I have a vector of these
> Marcin> "objects", and I want to display them in some way).
>
> People have already mentioned tabulated-list-mode.
>
> Another way to go is EWOC, also part of the Emacs core.
> EWOC is used at least by vc-dir but also I think some other modes.

Thanks a lot!  I looked into tabulated-list-mode and EWOC, and it seems
that EWOC is the way to go for me.

I have a few questions, though.  One thing I'd like to have is /sorting/
of the `things' in my ewoc based on different criteria.  Do I get it
correctly that I'll have to `ewoc-create' it from scratch?  DO I get it
correctly that I can just safely (setq my-ewoc (ewoc-create ...)),
knowing that the old one will be GC'ed automatically?

Also, I'd like to color various entries in my ewoc, using different
faces.  Do I get it correctly that I should assign them faces right
after `insert'ing them in my pretty-printing function?

> I would suggest using whichever one fits your needs best.
>
> Tom

Thanks again,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Seeking advice on writing a "line-based" major mode

[Stefan Monnier]

> correctly that I can just safely (setq my-ewoc (ewoc-create ...)),
> knowing that the old one will be GC'ed automatically?

You don't need to re-create the ewoc, but you can instead clear it
(e.g. with ewoc-filter) and then re-fill it.

> Also, I'd like to color various entries in my ewoc, using different
> faces.  Do I get it correctly that I should assign them faces right
> after `insert'ing them in my pretty-printing function?

Sounds fine, yes.  Sometimes it's more convenient to assign the face to
the strings before you insert them, but either way work fine.


        Stefan

Re: Seeking advice on writing a "line-based" major mode

[Marcin Borkowski]

On 2015-06-18, at 03:50, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> correctly that I can just safely (setq my-ewoc (ewoc-create ...)),
>> knowing that the old one will be GC'ed automatically?
>
> You don't need to re-create the ewoc, but you can instead clear it
> (e.g. with ewoc-filter) and then re-fill it.

OK, that's almost the same, but seems cleaner.  And since I'm keeping
the ewoc in a global variable (there is no point in having more than one
instance in my use-case), it is also trivial.

>> Also, I'd like to color various entries in my ewoc, using different
>> faces.  Do I get it correctly that I should assign them faces right
>> after `insert'ing them in my pretty-printing function?
>
> Sounds fine, yes.  Sometimes it's more convenient to assign the face to
> the strings before you insert them, but either way work fine.

Thanks.  I ended up with squeezing a `propertize' between `insert' and
`format'.  This has a disadvantage (AFAIU) of creating a copy of the
string, but since my ewoc won't have more than, say, 100 elements,
I don't think it will slow things down a lot.

>         Stefan

Thanks a lot,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Seeking advice on writing a "line-based" major mode

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> This raises two problems.
>
> 1. I want to be able to display these objects using
> some kind of a "template" (not unlike org's
> "property table", or dired's format etc.). I'd like
> this "template" to be configurable using a user
> option (with possibilities like "x characters for
> a name, then y characters for description, etc.
> for other fields").
>
> 2. When the point is one one of these lines, I want
> various keybindings to perform some actions on the
> object in question (like, again, in Dired or
> org-agenda).

Use the source, Luke!

If it is like Dired and org-agenda (?) then check out
that source.

It sounds like you can also benefit from checking out
the sources of `package-menu-mode',
`Buffer-menu-mode', and even the Gnus group and
summary modes if you are brave.

Dig in!

> Of course I could code all that myself - it doesn't
> seem to be too much work - but why reinvent
> the wheel?

Answer: because it is enjoyable, interesting, and
creative as you don't focus on understanding what
someone else did but instead on what you can do and
what you can learn how to do, thus getting exactly
what you want and nothing else - and besides, this
time a"round" you might stumble on something that will
revolutionize the entire pitch-black wheel industry!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Seeking advice on writing a "line-based" major mode

[Marcin Borkowski]

On 2015-06-08, at 00:23, Emanuel Berg <embe8573@student.uu.se> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> This raises two problems.
>>
>> 1. I want to be able to display these objects using
>> some kind of a "template" (not unlike org's
>> "property table", or dired's format etc.). I'd like
>> this "template" to be configurable using a user
>> option (with possibilities like "x characters for
>> a name, then y characters for description, etc.
>> for other fields").
>>
>> 2. When the point is one one of these lines, I want
>> various keybindings to perform some actions on the
>> object in question (like, again, in Dired or
>> org-agenda).
>
> Use the source, Luke!

Yeah, sure.  That's a good idea in general, but it has one drawback:
there's only 24 hours per day.

> If it is like Dired and org-agenda (?) then check out
> that source.

I might be tempted to look at Dired.  I'm scared of org-agenda source
code.

> It sounds like you can also benefit from checking out
> the sources of `package-menu-mode',
> `Buffer-menu-mode', and even the Gnus group and
> summary modes if you are brave.

Well, maybe I am brave, but I'm not mad.  Nor do I want to become
mad. ;-P

> Dig in!
>
>> Of course I could code all that myself - it doesn't
>> seem to be too much work - but why reinvent
>> the wheel?
>
> Answer: because it is enjoyable, interesting, and
> creative as you don't focus on understanding what
> someone else did but instead on what you can do and
> what you can learn how to do, thus getting exactly
> what you want and nothing else - and besides, this
> time a"round" you might stumble on something that will
> revolutionize the entire pitch-black wheel industry!

Again: in general, yes.  OTOH, there are so many other enjoyable,
interesting, and creative activities out there, even if you use
ready-made solutions to /some/ of your problems...  And writing rather
simple and boring Elisp code is not really very high on my list.  (Not
that writing Elisp is simple or boring in general: just that coding this
particular thing seems to me a lot like reimplementing well-known
things, and reimplementing a "format"-like function, for instance, seems
to be not very enjoyable/interesting/creative...)

But I agree with your previous point, studying someone else's code is
a good thing to do.  That is precisely why I assigned a fixed amount of
my time every day to studying code written by others.  I studied most of
ox-latex.el, some portion of AUCTeX source, some parts of simple.el...
Now I'm in the midst of digging through some C.  And I have to admit
that I learn a lot from this experience: both what to do and what not to
do...

Still, I hope that there /might/ be a general enough solution to my
problem so that I don't have to do it from scratch.

Thanks anyway

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Seeking advice on writing a "line-based" major mode

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> I'm going to start coding a major mode, a bit like
> dired or grep-mode or org-agenda mode, in which the
> buffer will contain a bunch of lines, each of them
> correspoding to some object (basically, I have
> a vector of these "objects", and I want to display
> them in some way).

By the way, "line-based" is confusing because it makes
you think about the line *editors* (e.g., ed).

But I understand what you mean so I suppose confusion
was kept at an acceptable level.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Seeking advice on writing a "line-based" major mode

[Marcin Borkowski]

On 2015-06-08, at 00:28, Emanuel Berg <embe8573@student.uu.se> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> I'm going to start coding a major mode, a bit like
>> dired or grep-mode or org-agenda mode, in which the
>> buffer will contain a bunch of lines, each of them
>> correspoding to some object (basically, I have
>> a vector of these "objects", and I want to display
>> them in some way).
>
> By the way, "line-based" is confusing because it makes
> you think about the line *editors* (e.g., ed).

What term would you propose for a library that establishes a one-to-one
relationship between some collection of objects and lines in some
buffer?

> But I understand what you mean so I suppose confusion
> was kept at an acceptable level.

I would hope so! ;-)

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Seeking advice on writing a "line-based" major mode

[Joost Kremers]

Marcin Borkowski wrote:
> And maybe there is even a more general library to establish
> a correspondence between some vector/list of objects and a buffer whose
> lines contain some textual representation of these objects, so that
> I wouldn't have to code e.g. the displaying routine from scratch?

I'm currently looking at tabulated-list-mode for something similar (or
not, depending on the details ;-) myself. It seems to have some of the
properties that you are looking for, although it's probably not a
perfect fit. Might still be worth a look, though:

(info "(elisp) Tabulated List Mode")

HTH


-- 
Joost Kremers                                   joostkremers@fastmail.fm
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)