unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: <bug-gnu-emacs@gnu.org>
Subject: bug#4250: 23.1; bookmark.el should raise reasonable error for empty filename entry
Date: Mon, 24 Aug 2009 15:14:50 -0700	[thread overview]
Message-ID: <2AB5A2C17C4C41FA8ED68F391075B631@us.oracle.com> (raw)

I have code that allows for bookmarks that have no filename, that is,
where the `filename' entry in `bookmark-alist' is `(filename)'.
 
It would be ideal and most reasonable if vanilla Emacs simply ignored
such a bookmark - tolerance. More generally, it would be great if it would
tolerate any bookmark in `bookmark-alist' that it doesn't recognize.
 
If that is not something you agree about, then at least it should
raise a reasonable error - not just "wrong-type-arg stringp, nil",
whenever a "malformed" bookmark is encountered.
 
The code in `bookmark-default-handler' is an example of the problem.
The local variable `file' is bound to (bookmark-get-filename bmk) -
which returns nil if there is no `filename' entry or the `filename'
entry is `(filename)'.
 
The code then simply calls (file-exists-p nil), via
(bookmark-file-or-variation-thereof nil), raising the wrong-type-arg
error.
 
In the alternative `if' branch, the code calls (find-file-noselect
nil), which has the same problem.
 
In general, it would be great if places where `bookmark-get-filename'
is called tested the result and treated nil by raising a
bookmark-level error.
 
As I said, it would be even better if the bookmark.el code could be
made tolerant of any bookmark whose format it does not
recognize.

bookmark.el already allows for applications and users to add new,
addtional entries. The problem is that it doesn't allow for
unexpected forms of the entries it predefines. It would be nice if it
were tolerant, and simply ignored any such bookmark (no error).
 

In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600)
 of 2009-07-29 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4)'
 







         reply	other threads:[~2009-08-24 22:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87d452mpo2.fsf@red-bean.com>
2009-08-21 22:38 ` bug#4229: 23.1; wrong-type arg: char or string-p, nil Drew Adams
2009-10-05  4:35   ` bug#4229: marked as done (23.1; wrong-type arg: char or string-p, nil) Emacs bug Tracking System
2009-08-24 22:14 ` Drew Adams [this message]
2009-10-05  4:35   ` bug#4250: marked as done (23.1; bookmark.el should raise reasonable error for empty filename entry) Emacs bug Tracking System
2009-09-13 22:22 bug#4250: 23.1; bookmark.el should raise reasonable error for empty filename entry Chong Yidong
2009-09-13 22:26 ` Karl Fogel
2009-09-14 20:29   ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2AB5A2C17C4C41FA8ED68F391075B631@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=4250@emacsbugs.donarmstrong.com \
    --cc=bug-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).